Let me have a guess :) On 25/01/2012 7:42 PM, Ross Boylan wrote:
On Tue, 2012-01-24 at 13:54 -0800, Ross Boylan wrote:
...
The code I want to test uses threads, but that is not entirely internal from the standpoint of the unit test framework. The unit test will be executing in one thread, but some of the assertions may occur in other threads. The question is whether that will work, in particular whether assertion failures will be properly captured and logged by the test framework.
I think it will - so long as your "test" on the main thread hasn't returned yet.
Concretely, a test may exercise some code that triggers a callback; the callback might come in a different thread, and the code that is triggered might make various assertions. There are two issues: whether assertions and their failures that happen in other threads will be correctly received by the test framework, and whether the framework is robust against several assertions being raised "simultaneously" in different threads. The latter seems a bit much to hope for.
I suspect both will be fine.
I assume that, at a minimum, the my test code will need to use locks or other coordination mechanisms so the test doesn't end before all code under test executes.
Yep - that's the only caveat I'd expect .
Finally, I'll mention two senses of threads in tests that my question does not concern, although they are also interesting. I am not concerned with testing the performance of my code, in the sense of asserting that an operation must complete before x seconds or after y seconds. Some potential implementations of such tests might use threads even if the code under test was single-threaded. The question also does not concern running lots of unit tests in parallel.
nose is still worth having a look at - personally I just use it as a runner and where possible ignore its api...
Mark -- http://mail.python.org/mailman/listinfo/python-list
