Open GoogleCodeExporter opened 9 years ago
These changes look good. I will look at them over the next few weeks and try to
figure out how to integrate into MultithreadedTC
Original comment by nat.aye...@gmail.com
on 25 Aug 2009 at 4:37
Hi Jan, I recently joined as a committer.
If you are still interested in contributing this feature, please prepare a
patch and attach it to this issue. I'll be happy to review and apply it.
Original comment by tom...@google.com
on 28 May 2011 at 8:35
I stumbled upon this issue and thought I'd help by making a patch of Jan's
work. It's basically all Jan's code merged by hand with newer changes from the
trunk. I've also updated all the unit tests.
Some notes:
1. There's still some work that can be done to make mtc even more JUnit 4
friendly. http://code.google.com/p/multithreadedtc-junit4/issues/detail?id=2
deals with using a Runner instead of having to subclass MultithreadedTestcase.
Really, there needs to be a discussion with how we want to associate thread
methods with tests. Right now, that's done by grouping them together in a
MultithreadedTestCase instance, but that means you have to use a lot of nested
classes in your tests (see the patched unit tests for examples). I'm not sure
using a Runner solves this.
2. This patch breaks backwards compatibility. You have to use JUnit 4 and the
new style of mtc tests (e.g. you have to use @Threaded instead of naming
conventions). If we really want backwards compatibility, that can be done with
some more work.
3. MultithreadedTestCase.finish() doesn't work. initialize() works if you
annotate it with @Before, but finish() will NOT work with @After. This is
because @Before and @After run before/after each test, but initialize/finish
run before/after the threads. @Before will still get run before the threads are
started because of some esoteric JUnit behavior, but @After runs after the
tests (not in between threads and test). This actually isn't that bad though,
since most of the time (at least in the mtc unit tests), finish() is being used
to check assertions after the threads have finished. A @Test does that just
fine.
Original comment by GabeGore...@gmail.com
on 6 Oct 2011 at 7:52
Attachments:
Hi Gabe, thanks for the patch.
2. I think we don't want to break compatibility with JUnit3.
3. Also I think we need to have an alternative to provide the current behavior
with JUnit4, changing the finalize for a tearDown is similar, but not exactly
the same, and may break a lot of uses.
Original comment by tom...@google.com
on 7 Oct 2011 at 2:09
Thanks for the feedback.
I'll rework the patch to maintain backwards compatibility. I think we will end
up having a separate JUnit4MulithreadedTestCase class. That way, it won't be
ambiguous as to whether mtc should look for JUnit 3 or 4 conventions.
I'll also try to add an @AfterThreads construct so that a method can be run
after the threads have terminated but before the tests are run.
Original comment by GabeGore...@gmail.com
on 7 Oct 2011 at 7:09
Here's the updated patch. It keeps backwards compatibility with the old JUnit 3
behavior, adds a new MultithreadedJUnit4TestCase, and adds an @AfterThreads
annotation.
Original comment by GabeGore...@gmail.com
on 8 Oct 2011 at 6:13
Attachments:
Any update ?
Original comment by joseph.g...@gmail.com
on 13 Mar 2014 at 4:42
Any update ?
Original comment by fabien.d...@webmails.com
on 5 Jan 2015 at 8:45
Original issue reported on code.google.com by
janvanbesien@gmail.com
on 25 Aug 2009 at 10:44