manojsahu4u / multithreadedtc

Automatically exported from code.google.com/p/multithreadedtc
0 stars 0 forks source link

JUnit 4 enhancements #4

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I made some enhancements for JUnit 4. See http://
janvanbesien.blogspot.com/2009/06/modernizing-multithreadedtc-junit-4.html 
for details. I would be happy to contribute them.

Original issue reported on code.google.com by janvanbesien@gmail.com on 25 Aug 2009 at 10:44

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
Any update ?

Original comment by joseph.g...@gmail.com on 13 Mar 2014 at 4:42

GoogleCodeExporter commented 9 years ago
Any update ?

Original comment by fabien.d...@webmails.com on 5 Jan 2015 at 8:45