unittest and threading

[Mark Hammond]

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