unittest and threading
skippy.hammond at gmail.com
Wed Jan 25 06:24:48 EST 2012
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
I think it will - so long as your "test" on the main thread hasn't
> 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
nose is still worth having a look at - personally I just use it as a
runner and where possible ignore its api...
More information about the Python-list