[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.
ok.
>>> 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.
Thanks,
r.
--
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