[TIP] Fwd: Testing multi-threaded applications

Michael Foord fuzzyman at voidspace.org.uk
Wed May 9 05:49:12 PDT 2007


Raphael Marvie wrote:
>
> On May 8, 2007, at 6:48 PM, Michael Foord wrote:
>
>> Sorry for the top post - long post to reply to,
>>
>> Shouldn't you use the normal test patterns?
>
> Usually I go backward regarding your "normal test patter" I start with 
> the writing of the functional / acceptance test, and then I write 
> "additional" unit tests when I need them to complete a particular part 
> of my system.
My 'pattern' wasn't meant to imply an order. The order you suggest is 
the 'correct' one, and the one we use.

>
>> Test the individual components (test each thread as if it was single
>> threaded).
>
> Done.
>
>> Test the logic that uses the components (the locking and code that
>> launches threads).
>
> Done.
>
>> High level (functional) tests that test the features work as expected.
>
> Yes, but the problem lays in the writing of those tests? Cf how to 
> define a timeout to consider threads should have finish their task, 
> and if they do not have consider the test has failed? In other words, 
> testing a multi-threaded application seems to imply taking time into 
> account when defining asserts. But identifying this time factor is not 
> trivial.
>

Our application is multithreaded, so we have the same issue.

We use a 'waitfForCondition' pattern - that waits with a timeout for the 
background thread to finish recalculating before checking the results in 
the user interface.

It does have a timeout, which is partly arbitrary, but which also acts 
as performance safeguard - as it sets a maximum acceptable limit for the 
calculation to take.

If you abstract out the differences between multi and single threaded 
into your 'waitForCondition', then the rest of the test can appear to be 
the same.

HTH ?

Michael Foord
http://www.voidspace.org.uk/python/articles.shtml


> Moreover, my motivation was to write a single functional test for two 
> implementations that could be threaded or not. And the more I go the 
> less I think I can reach this point as the logic is completely different.
>
>
> -- 
> Raphael Marvie, PhD                http://www.lifl.fr/~marvie/
> Maître de Conférences / Associate Professor  @  LIFL -- IRCICA
> Directeur du Master Informatique Professionnel spécialité IAGL
> Head of Master's in Software Engineering     +33 3 28 77 85 83
>
>
>




More information about the testing-in-python mailing list