Dear Vaclav,
I wrote a first draft of a decorator: change_environ [0], that:
1. overwrite the environment variables,
2. execute the test and
3. restore the environment variables.
Probably I should modify the function with something like:
{{{
try:
func(*args, **kwargs)
finally:
# restore the environment variables
for k, v in envs.items():
oval = original_envs[k]
if oval == NOT_FOUND:
os.environ.pop(k)
else:
os.environ[k] = oval
}}}
Otherwise if the function raise an exception the current
implementation will not restore the environment variables back to
their original value.
But I think this kind of functionalities is general enough to be
somewhere in the gunittest code.
What do you think? Any idea?
All the best.
Pietro
[0] https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/script/testsuite/test_utils.py#L10
On Tue, Mar 29, 2016 at 6:49 AM, Pietro <peter.zamb@gmail.com> wrote:
- overwrite the environment variables,
- execute the test and
- restore the environment variables.
In case the test involves just calling subprocesses, the best way probably is to change their environment instead of changing the global one. This is not applicable to function calls of course.
Otherwise if the function raise an exception the current
implementation will not restore the environment variables back to
their original value.
Although I can see advantages of decorators, Python unittest package uses setUp() and tearDown() functions for that purpose. Introducing another mechanism might interfere with the execution of the tests. If nothing else, you would need to re-raise the exception to signal that the test failed. I suggest to try setUp() and tearDown() as unittest advocates and only when it won’t work look at decorators (which are used in unittest but it different way).
Vaclav
Hi Vaclav,
On Tue, Mar 29, 2016 at 3:02 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
Although I can see advantages of decorators, Python unittest package uses
setUp() and tearDown() functions for that purpose. Introducing another
mechanism might interfere with the execution of the tests. If nothing else,
you would need to re-raise the exception to signal that the test failed. I
suggest to try setUp() and tearDown() as unittest advocates and only when it
won't work look at decorators (which are used in unittest but it different
way).
ok, I changed it in r68183, now is using setUp and tearDown.
All the best
Pietro