jamadden
commented
6 years ago That’s not terribly surprising, this is some of our oldest code...
I was looking at tests in the stdlib today, and a number of them capture the cwd in setUp and restore it in tearDown, so we’re not the only ones with this issue. There’s precedent to solve it that way.
Other than that, I would suggest a context manager in the app code that changes Dirs. I think I’ve seen that somewhere too.
When running the tests the working directory is changed as part of some tests but never reset back to the working directory prior to the test. This leads to an unexpected working directory at the end of the process depending on the order in which the tests are invoked. This manifests itself in potentially odd behaviours in some test runners. For example running using the xml based zope testrunner results in the xml output being written to an unexpected place (it is written to the current working directory as configured in buildout).
I initially took a pass at trying to make sure that code that changed the current working directory reset it back to the correct value when appropriate. However that seems to be a difficult task as there is a fair amount of that going on in non test code. As I got further and further down the rabbit hole I lost my confidence in being able to disect what needed to change where. We should probably take a pass here and try and clean up usage of os.chdir.