Remove redundant temp folder and unused imports

[MVrachev]

Description of the changes being introduced by the pull request:

In many of the tests classes, we are creating two
temporary directories: one with the name "temp_<random_string>"
and inside it, we generate a new directory for each test with the name
Test<Class_Name>_<random_string>.

I think we don't need the "temp_<random_string>" directory.
The only benefit I can think of is that it could contain multiple
temp folders from failing tests from a particular test run.
But even then, this is not a big bonus because the name
temp_<random_string> is not really descriptive from which test
run this directory was created.

PS: Thanks to Jussi Kukkonen who noticed we are using two temp
folders per class in our tests.

Signed-off-by: Martin Vrachev mvrachev@vmware.com

Please verify and check that the pull request fulfills the following
requirements:

• The code follows the Code Style Guidelines
• Tests have been added for the bug fix or new feature
• Docs have been added for the bug fix or new feature

[joshuagl]

Thank you for taking the time to clean this up. I have a few minor comments, mostly on not adding semi-redundant comments to the code.

[MVrachev]

Addressed all of @joshuagl comments and:

1. Replaced import tuf.unittest_toolbox as unittest_toolbox with from tuf import unittest_toolbox in all of our test files.
2. Removed the comments I have added such as We are inheriting from custom class. from all of the tests.
3. Replaced all unittest_toolbox.Modified_TestCase.function(self) calls with super().function() in all of our tests.

[MVrachev]

It seems like because we are supporting Python 2 we have a problem with
super().function() which I used because in Python2 it is super(self).function()
Probably I should replace it with unittest_toolbox.Modified_TestCase.function(self) the way it was?

[joshuagl]

Ah, yes. The syntax changed for super() between Python 2 and Python 3. Let's leave it as is for now and we can fix this later when we've purged Python 2 from our codebase.

[joshuagl]

Would be good to get this cleanup landed. @MVrachev could you revert back to unittest_toolbox.Modified_TestCase.function(self) when you have some cycles? Thank you.

[jku]

I'm a bit worried about

• using os.getcwd() for the location where temp dirs are created
• the fact that sometimes temp dirs are not cleaned up (is this only when test run is cancelled? not sure)
• after this PR probably creating more temp dirs in current dir (one per instance instead of one per class I guess?)

So I wonder if this should only be done if we also start creating the temp dirs somewhere more reasonable?

Does anyone know when the temp dirs are not being removed?

[sechkova]

Does anyone know when the temp dirs are not being removed?

Besides the expected case when tearDown is not called due to some error, I've noticed temp dirs not being removed on Windows with "being used by another process" error. Unfortunately, I can't say which is the process and I haven't observed this consistently in other environments.

[sechkova]

So I wonder if this should only be done if we also start creating the temp dirs somewhere more reasonable?

I would vote for that if possible. Polluting the tests source code dir on a failure is not particularly harmful but ... unpleasant

[MVrachev]

I'm a bit worried about

• using os.getcwd() for the location where temp dirs are created

• the fact that sometimes temp dirs are not cleaned up (is this only when test run is cancelled? not sure)

• after this PR probably creating more temp dirs in current dir (one per instance instead of one per class I guess?)

Yes, the side effect is that it will create one temp dir per class instance.

So I wonder if this should only be done if we also start creating the temp dirs somewhere more reasonable?

As I understand it, the idea is to have those temp files available for you on test failure for analysis.
Probably it will be better to choose a deterministic path where they can be found, but where should that be?
Maybe ~/tmp?

Does anyone know when the temp dirs are not being removed?

The doc says:
tearDown:

Method called immediately after the test method has been called and the result recorded. This is called even if the test method raised an exception, so the implementation in subclasses may need to be particularly careful about checking the internal state.
...
This method will only be called if the setUp() succeeds, regardless of the outcome of the test method. 

Again from the doc for tearDownClass:

If an exception is raised during a setUpClass then the tests in the class are not run and the tearDownClass is not run. 

Also again in the doc

Skipped tests will not have setUp() or tearDown() run around them. Skipped classes will not have setUpClass() or tearDownClass() run.

[joshuagl]

As I understand it, the idea is to have those temp files available for you on test failure for analysis.
Probably it will be better to choose a deterministic path where they can be found, but where should that be?
Maybe ~/tmp?

Python has a function to get an OS appropriate, administrator configurable, temporary directory tempfile.gettempdir(). As well as providing functions to create directories within that host appropriate location: tempfile.mkdtemp(), and tempfile.TemporaryFile().

[sechkova]

Does anyone know when the temp dirs are not being removed?

Besides the expected case when tearDown is not called due to some error, I've noticed temp dirs not being removed on Windows with "being used by another process" error. Unfortunately, I can't say which is the process and I haven't observed this consistently in other environments.

Sorry for giving you a bit random hints and not direct answers but in the Windows case temporary files created by unittest_toolbox.Modified_TestCase.make_temp_data_file cannot be cleaned due to
PermissionError(13, 'This process cannot access the file because it is being used by another process').

But this is a Windows VM so it can be something specific to this case ...

[MVrachev]

Blocked, until we remove Python2 from our tests as Joshua has mentioned.
#1224 (comment)

[MVrachev]

After the removal of python2 test cases in 13b0857 I rebased and updated this pr.

[MVrachev]

Honestly, I am wondering about this change.
On one hand, on a successful test run, we had generated multiple additional folders for each test class,
on another hand, on an error probably we will end up with many folders for each test class that failed, right?

[jku]

I might have broken this PR quite badly with a recent bug fix (moved chained up teardown calls to the correct place in #1346 to fix issues found in another PR). Sorry about that -- I did not remember this one.

I think that PR also makes this one a bit less needed: at least in the tests that I touched I made sure that we only try to remove the "topmost" directory (because that will remove every other directory inside it). In some cases there might still be unneeded temp directories.

Let's discuss when you are back.

[MVrachev]

As I said before, I don't feel so confident about this change anymore.
I will just close it for now and if somebody complains about it in the future, I will reopen or push another one.