Hi John,
Thanks for the reply, that was really helpful. The TestBarrier
class does the trick. That was the only class I needed, the class
is quite small, and I need to make some modifications to it, so I
copied the class into the databinding test bundle rather than
create dependencies to the platform tests.
Nigel
On 07/03/2014 15:40, John Arthorne wrote:
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
<nigelipse@xxxxxxxxxx>
To:
e4-dev@xxxxxxxxxxx,
Date:
03/04/2014 07:52 AM
Subject:
[e4-dev] Unit
testing multi-threaded code
Sent by:
e4-dev-bounces@xxxxxxxxxxx
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
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
|