[TIP] Fwd: Testing multi-threaded applications

Raphael Marvie raphael.marvie at lifl.fr
Wed May 9 06:32:56 PDT 2007

On May 9, 2007, at 2:49 PM, Michael Foord wrote:

> 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.


>>> 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.

My solution with wait_for_some_time() is similar then, but your  
wait_for_condition naming sounds better to me. In the meantime, I  
still cannot help my students choosing that timetout (and my students  
too often ask me for recipes).

> 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 ?

Yes, I have reach the same conclusion. I can accept the small noise  
introduced by waitForCondition() in my non-threaded version tests.



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