[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[virgo-dev] Test framework for MultiThreaded tests
- From: Olivier Girardot <ssaboum@xxxxxxxxx>
- Date: Wed, 11 Aug 2010 15:52:57 +0200
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=kGep/m0mA3rSYqQ+pyp5tfRHqGXxjACMR3kEaT8/EYewIFdhdp8CbRVKVZg0Xjl2nD l4LlC1B+zZTyhLDp2rZK4TECOfVvBy0BIusl+cQMSOj9lz+xeQ4hjCEFxiMVvt6yf/WB BU59cu2gy2BRVclwpVPZ7R9ri70NuKylblw3s=
i edited the wiki page Steve P. created about multi-threaded tests, i did a lot of testing and research to find a clean and easy way to handle the problem we found out during the creation of the test case https://bugs.eclipse.org/bugs/show_bug.cgi?id=321397
. Steve summed it up in a clear manner on the wiki :
- Child threads that make assertions have the results of those assertions undetected.
The (child) threads can terminate before or after the main thread (which is running the JUnit test), so even if the child assertions are correctly reported, there may be no-one to report them to. (Note that the overall result of a test needs to be gathered, too, so some sort of synchronisation is vital.)
- Mock objects (which make implicit assertions during use and on verify) shared between threads can have their assertions caught (as in the answer to the first problem) but verify calls need to be made after all the child threads have finished, or at least not too soon.
So what should we do ?
I thought about many ways we could handle that but the perfect solution isn't designed yet, so i submitted the following proposals :
- (old one) Brian Goetz mentionned in Java Concurrency in Practice that for the JSR 166 (creating the java.util.concurrent package) a test framework was created to handle assertions error in generated threads. I found back the class : JSR166TestCase and we should take a look;
- We can handle these problems using ThreadGroups exceptions handling, but exceptions will be ducked back into the "root" ThreadGroup. Killing potentially generated Threads;
- (new one) Using aspects to watch for AssertionsError, no matter what thread will launch it. This is the less intrusive way but its scope must be carefully studied. (Binary weaving can be painfull (especially on the 16 000 jdk classes), i think we should use Load Time Weaving as much as possible but it has to be tested).
I'd love some reviews on these and know what you think