When running tests bundled with a library it would be useful to be able to run some initialization code before tests are being run so that one can configure options pertaining to logging for example.

For this reason it would be useful to have a new command line option handled by unittest.main() for running custom Python module before running tests.

See http://stackoverflow.com/q/8607767/95735

Can you give an example of what you would like the API to look like (i.e. what you would like to be able to type from the command-line if, say, configuring logging as in the SO post)?

I'm not sure I understand why a wrapper script isn't a good enough solution, as described in the accepted answer on SO.

I would do this with a module level (global) flag as to whether the initial set up has been done and a BaseTestCase class that checks this flag and calls a set up function if it hasn't been done yet (and then sets the flag).

@Chris

The example given by Holger Krekel (http://stackoverflow.com/a/13094042/95735) showing how it can be done with pytest is exactly the thing I had in mind. It would be good to have this feature incorporated into unittest.

@Michael

I guess checking this flag must be protected by a lock in case test cases are run in parallel. If so wouldn't this be kind of a bottleneck? Is this flag necessary? Can't we just assume that initialization code had already run when any testcase runs?

There's interesting question how would initialization code be run in case of auto discovery. In the simplest form it would be run just once before all modules with tests are run. But it would be interesting to allow running initialization per test module. To support this unittest should somehow pass name of test module to be executed to initialization code. Alternatively there could be some special named init files which would be run before running test modules.

@piotr
Yes, protecting the set up with a lock would be easy, although unittest doesn't directly support running tests in parallel anyway.

Is there any common use case other than logging? For example, logging could be covered by an additional command-line argument for unittest.main(), e.g.

--logconfig /path/to/logging-config.json

which would cause unittest.main() to load the JSON in the specified file (expected to be a suitable dict) and pass it to logging.config.dictConfig().

That would handle a perhaps not uncommon use case without the user having to write any code, but rather just provide a suitable logging configuration.

@Vinay
I don't see other use cases but maybe guys behind py.test, where there is such a feature could come up with other use cases.
The solution with passing config dict in a new command line parameter seems to be enough as long as logging is concerned. However it's not as versatile as custom initialization code of course.

I always solve the logging problem with test-development-production configuratins and ensuring that running tests imports the logging setup. I've never wanted / needed to configure logging from the command line.

@Michael: When unit testing one's own projects, I agree with you. But I think Piotr's use case is when you download some new library from PyPI or clone it from GitHub/BitBucket/etc., and you want to run tests on that code without changing any of it, as you're just exploring at this point. Now ideally you'd just be able to do e.g.

python setup.py test --logconfig filename.json

or, if it isn't set up to do that, at least look for a test folder with scripts that have 'if __name__ == "__main__": unittest.main()', which I can then run. In either of these cases, even if the library I'm testing uses logging, I can't readily make use of it to look at DEBUG messages, say, unless I write some code (not much code, I grant you).

Of course, once you get to the point where you've decided to use that library in your project, you would integrate its logging setup with the logging setup of your own code, in your tests.

Is this logging specific issue an actual problem or a theoretical problem? It's not a problem I've ever seen (myself), nor the one the issue was opened for.

Not an actual problem (for me), and although the issue was opened for more general functionality, logging is the only specific use case that was actually cited.

> But I think Piotr's use case is when you download some new library (...)

Yes, indeed.