Hi Nigel, some thoughts: - The most important thing is putting all blocking code into jobs/threads and not run anything that may deadlock in the main test thread because it can kill a whole test suite. All tests should be forking off the real test, and then the main test waits with a bounded timeout for completion. - There is some basic infrastructure in the org.eclipse.core.tests.harness bundle, such as TestJob and TestBarrier. TestBarrier is used heavily in platform tests, but you could use the Semaphore classes in java.util.concurrent with similar effect. - Essentially using a semaphore lets you strictly control the order of execution between multiple threads, making the test predictable and nearly equivalent to a single-threaded test. Tests need to be clearly repeatable wherever possible, rather than just running a concurrent activity 100 times and maybe it will fail, maybe not. - Having tests rely on an unapproved library that everyone running tests will need to install separately is a no-go. If it is really valuable we can enter a CQ and get it added as a proper dependency.
Good luck, concurrency testing is really hard! John From: Nigel Westbury <[email protected]> To: [email protected], Date: 03/04/2014 07:52 AM Subject: [e4-dev] Unit testing multi-threaded code Sent by: [email protected] I was wondering if there were any recommendations on how we write unit tests for multi-threading code. I am writing tests for https://bugs.eclipse.org/bugs/show_bug.cgi?id=425704 (making obserables thread-safe). I have used https://code.google.com/p/multithreadedtc/ very effectively on other projects. It is published under the BSD license, which we probably can't commit, so would that mean users would have to install manually to run the tests? _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
