Community
Participate
Working Groups
Hello, I'm probably very fast with entering this feature request, but with JUnit 4 in the works, I would like to verify that JUnit 4 will get integrated into Eclipse very soon. JUnit 4, requiring Java 5, uses Java annotations to mark test methods, setup and teardown methods and test decorators. This will probably have an influence on how Eclipse should collect all test methods as well as on the integrated Eclipse JUnit test runner. Ringo
Eclipse 3.1 can already execute JUnit 4 tests. Have you tried it ;-). All you have to do is to use the test execution adapter provided by JUnit 4 inside the suite method.
The adapter based integration is imperfect. It works for whole classes but not indiivdual methods. That is, the tests in org.junit.samples.ListTest by selecting the class in Package Explorer and choosing Run As JUnit test from the context menu. The tests pass. Cool! However, if instead of selecting the entire test I just select one test method; e.g. contains(); then the test fails like so: junit.framework.AssertionFailedError: Could not create test 'contains' at junit.framework.Assert.fail(Assert.java:51) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner$2.runTest(RemoteTestRunner.java:557) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:120) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) I don't suggest working on this until JUnit 4 is released, but once it is this is worth addressing.
We are working on a full JUnit4 integration for 3.2.
Created attachment 27534 [details] Proposed patches and tests for JUnit 4 support in Eclipse This is an interim post of the patches I'm proposing to introduce full JUnit 4 support into Eclipse, with the option of running against a JUnit 3 / Java 1.4 runtime as well. The current status: Currently the following work for both JUnit 3 and 4: 1) Run tests by manually creating a test configuration 2) Navigate to failure method 3) Rerun failing test from failure or hierarchy tabs 4) Run all tests in a container by manually creating a test configuration 5) Run plug-in tests This is half done, but currently broken: 6) Run As > JUnit test correctly runs either JUnit 3 or 4 tests These work in JUnit 3, but not yet JUnit 4: 7) Rerun button from JUnit view 9) Stop button from JUnit view 10) Compare values in a comparison failure I've broken this in JUnit 3, and it doesn't work yet in JUnit 4: 8) Rerun failures first This doesn't work yet: 11) Automatically run all JUnit 3 and JUnit 4 tests in a project simultaneously And I know exactly the refactoring that has to happen for this, but haven't done it yet: 12) Do not require 1.5 JVM when running only JUnit 3 tests. I've been planning all along with the assumption that there will be some users that have only a 1.4 JVM, and therefore can only use JUnit 3.8. This will require splitting up the junit.runtime plug-in, which makes patching more complicated, so I've been putting it off for now. To get started trying this out, unzip the attached file, and look at eclipse-junit4-root/README. This is not for the faint of heart--these are big patches against CVS, with some legwork to get them working. However, feedback is appreciated. I'll try to keep further updates coming every couple days as items get checked off the list above. Unfortunately, the JMock binaries I've been using are too big to post, so you'll have to get them from subversion, as described in the README file. I'll post the tests as a different attachment.
Created attachment 27535 [details] The tests for JUnit, which go with the previous patch
Created attachment 28100 [details] Updated patches and tests for JUnit 4 in Eclipse New status: Currently the following work for both JUnit 3 and 4: 1) Run tests by manually creating a test configuration 2) Navigate to failure method 3) Rerun failing test from failure or hierarchy tabs 4) Run all tests in a container by manually creating a test configuration 5) Run plug-in tests 6) Run As > JUnit test correctly runs either JUnit 3 or 4 tests These work, but do not have tests in JUnit 4: 7) Rerun button from JUnit view 10) Compare values in a comparison failure This partially works: 9) Stop button from JUnit view (only stops between classes, not between methods) I've broken this in JUnit 3, and it doesn't work yet in JUnit 4: 8) Rerun failures first This doesn't work yet: 11) Automatically run all JUnit 3 and JUnit 4 tests in a project simultaneously And I know exactly the refactoring that has to happen for this, but haven't done it yet: 12) Do not require 1.5 JVM when running only JUnit 3 tests.
Created attachment 28101 [details] Updated tests for JUnit
Hi David, thanks a lot for the patches. Unfortunatelly we didn't find any time to look at them in the M3 time frame (lots of us were on vacation). Markus Keller will be our new man for JUnit. Our idea is to have JUnit4 integration and some sort of test model for Eclips itself. I have asked Markus to look at this during the M4 time frame and he will look at the patches you have provided so far. Markus, a small tip: the patches are zips which contain a lot of unneccessary stuff. The interesting file are the patch files in the root of 'eclipse-junit4-root'
Dirk, Sorry, I thought I had added myself to the CC list when I posted the patches. I'm happy to devote more time to this, and I look forward to feedback from Markus soon.
David: I'm currently reorganizing the jdt.junit plugin to create a model for test sessions. I had a look at your patches and I think it's easier for me to make the model first and then adapt to JUnit 4. As soon as I'm done with the model, I'll integrate JUnit 4 support from your patches.
Markus, I'd be happy to refit my patches to the new JUnit-with-model. Would that be useful?
Created attachment 33736 [details] Patches for existing JUnit-facing Eclipse plug-ins
Created attachment 33737 [details] New plug-ins for handling junit 4
I've attached the latest patches. The chief advances are: 1) The patches are clean, without svn or CVS junk 2) The patches are against Markus' JUnit w/ Model patch, sent to me in mid-December 3) They work with (and contain) the CVS version of JUnit 4 from this morning, which has changed rather drastically from before. 4) Classes annotated with @RunWith are recognized as JUnit 4 test classes Known problems: 1) Run with failed first has not yet been fixed 2) Does not automatically run all JUnit 3 and JUnit 4 tests from a project simultaneously 3) Still requires JRE 1.5 even for JUnit 3 tests. Fixes for these are coming soon. Please provide feedback--it would be great to have Eclipse support JUnit 4 at the same time that JUnit 4 goes final.
Created attachment 34180 [details] Patches for existing plug-ins, version 2006 Feb 06
Created attachment 34181 [details] New plug-ins for handling junit 4, version 2006 Feb 06
This latest version has a couple fixes. It runs with the updated JUnit 4 API. Most importantly, each test kind can now specify its own runtime classpath, meaning that JUnit 3 tests can run on top of old JRE's, and not require the JUnit 4 jars.
Created attachment 34258 [details] Patches for existing plug-ins, version 2006 Feb 06b Against HEAD, with proper copyright headers
Created attachment 34259 [details] New plug-ins for handling junit 4, version 2006 Feb 06b With proper headers, compiles against HEAD
*** Bug 128376 has been marked as a duplicate of this bug. ***
A note to Juergen, who posted bug 128376: If you use JUnit 4's backwards compatibility, you can run your JUnit 4 tests in Eclipse. Add to your suite or test class: public static Test suite() { return new JUnit4Adapter(ThisClass.class); } Let me know if this works for you. Thanks.
> Add to your suite or test class: > public static Test suite() { > return new JUnit4Adapter(ThisClass.class); > } > Let me know if this works for you. Yes, this works fine.
This is great stuff. Are we looking at 3.2 M6 as a timeframe for expecting this?
> Are we looking at 3.2 M6 as a timeframe for expecting this? Yes, that's the plan. Sorry that I forgot to set the milestone. We're sorting out some last legal and technical issues before this can be released.
We now got legal approvement for adding JUnit4, but it's unfortunately too late for M6. Moving to RC1.
It was my understanding that M6 marked 'feature freeze' for the 3.2 release. Is it really possible that Junit4 support will be rolled into RC1? Wouldn't that constitute a new feature?
As stated in the end game plan, new features for RC1 need PMC approval. I'll do that request as soon as we ready.
Sorry for asking questions within this bug, but is there a short description on how to use JUnit 4 within Eclipse 3.2. I've just tried Eclipse 3.2RC1 and I still have to extend my class from TestCase and need to provide a suite() method that returns a new JUnit4TestAdapter. Otherwise I cannot run my test class as JUnit test.
(In reply to comment #27) > As stated in the end game plan, new features for RC1 need PMC approval. I'll do > that request as soon as we ready. > getting JUnit4 support into the RC has PMC approval
released updated JUnit 4 wizard, new JUnit classpath container, updated quick fixes > 20060421
(Various API additions in org.eclipse.jdt.junit.wizards.NewTestCaseWizardPageOne)
Released support for JUnit4 > 20060426. Launch Configurations can now specify a JUnit4 Test Loader. Please open new bug reports if you find problems with the solution in the upcoming builds.
Grrr... sorry for the spam. Setting to FIXED.
With this code we now have a codemetrics warning: Bug: Useless object stored in variable input of method org.eclipse.jdt.junit.wizards.NewTestCaseWizardPageOne.performBuildpathConfiguration(Object) Our analysis shows that this object is useless. It's created and modified, but its value never go outside of the method or produce any side-effect. Either there is a mistake and object was intended to be used or it can be removed. This analysis rarely produces false-positives. Common false-positive cases include: - This object used to implicitly throw some obscure exception. - This object used as a stub to generalize the code. - This object used to hold strong references to weak/soft-referenced objects. else if ("c".equals(data)) { // open compliance //$NON-NLS-1$ String buildPath= BUILD_PATH_PAGE_ID; String complianceId= COMPLIANCE_PAGE_ID; Map input= new HashMap(); input.put(KEY_NO_LINK, Boolean.TRUE); PreferencesUtil.createPropertyDialogOn(getShell(), javaProject, buildPath, new String[] { buildPath, complianceId }, data).open(); } commit 6358a4e5c327b982f65559899249f361069a4c3c Author: Martin Aeschlimann <maeschli> 2006-04-20 16:52:27
