Daniel Russel wrote: > Is it possible to have unittest run each test in a separate process? > That we we don't have to worry about bad memory accesses in one test > crashing python and messing up later tests (and hence can leave failed > tests in until we can actually fix them). We are kind of abusing > unittest (by using it to test C++ code) so it may not be easy to do.
It is possible, but it'd be ugly, and I don't think it would be an 'improvement', since it would hide a multitude of sins (the OS does a lot of cleanup at process end which hides various bugs). You can always run your tests individually if you so desire. But the nightly builds do not complete if any of the tests fail, regardless of whether they're run in separate processes, and then people queue up at my desk the next day to complain about New Feature X not being usable yet in the nightlies. That's the primary reason why I insist on things not being broken for more than a day or two at a time.
The Python unittest tests are not for testing C++ code, but the Python interface. If you want to write tests for something which is not exposed to Python, it makes more sense to write C++ tests rather than exposing it just so you can test it. I seem to recall that Boost has a unittest framework, which would probably be the best thing to use here. We don't have any C++ tests yet because nobody has written them, but I'm certainly not averse to them in any way. Of course, if the functionality *is* exposed to Python, you'll need a Python testcase, at a minimum to make sure the SWIG wrapping is working correctly, so you may as well use this Python testcase to also test the underlying C++ code unless you want to have a lot of overlap in the testcases.
Ben