Community
Participate
Working Groups
I've been using JUnit with Eclipse for quite a while and the more I use it the more I feel that it does not match with the rest of Eclipse views. If you are familiar with Navigator, Package Explorer, Synchronize and some other views, then you can remember that each of them allows you to choose Working Set in order to reduce number of visible entries for the current activity. When your activity is focused around implementing unit tests, running and debugging them it will be interesting to have a solid view for all existing test cases within your scope of work (e.g. project, package, class). That bring us to the hierarchical tree similar to Package Explorer that shows all existing tests, including test suites with grouped or even generated test cases (it means that all tests has to be compiled and if there are suite()'s, they has to be executed at this step). Each test should allow quick navigation to the tested code and test case implementation (or to suite() method). User can select multiple packages, test suites or even concrete test cases for the execution. That hierarchical view should also show state of the last execution of these tests and also if the code or unit tests itself were modified (so you can't rely on the result of last test). Actually it could be bit complicated to track dependencies from the changed class and also mark changed tests that depends on the changed code. Unit test view should also allow selecting a working set in the same way as it is done for other views. Please let me know what do you think about it.
The current JUnit view is an "output" view like the console, the search results view, or the problems view and it is consistent with other eclipse views, i.e., it shows you the output of an operation. Given that tests are typically separate from the production code (test source folder, test project) there is no need for a special tests view. You can use the existing views and their working set support to focus on tests. The last state of a test could be shown in the existing package explorer as a decoration and this would be an interersting enhancement, but isn't planned for 3.0. You might want to check out the "Contributing to Eclipse" book, in there is a JUnit integration that treats test failures like compile errors. This is also something we would be interested in, but not for 3.0
Erich, existing integration works well untill you stat heavily using TestSuites and if number of tests is relatively small. My proposal should allow to handle suites and also large number of tests. As you know, there was requests already to enable to rerun only particular tests, to existing output-like JUnit view does not handle very well. From other hand views like package explorer and outline does not allow you to see the solid picture for tests, because they show a lot of noice not related to testing. Atually it could be an option to have a special kind of filter that will hide all non test code from packages and members view, but I no sure how to handle suites this way. By the way, there are Ant view for build.xml's (wich you can also see in navigator and packages views) and there are nothing wron with that. It would be really convenient to have solid view for tests only (even so tests are separated from the production code), that will show test statuses and will allow to rerun tests easily.
After rethinking the goals of the proposed change, I'd like to reopen this bug to get an additional comments. I think that the main goal is to cover test suites better. Right now Eclipse provides very limited and very inconvenient support for running and debugging test suites. I have suites that include from 600 to 5000+ testcases generated based on the external test data. Eclipse only shows these in JUnit view when you run the suite. That view does not allows to run only choosen testcases (e.g. only failed or changed) and also does not allow to set a break point on the selected testcase.
Looks like there is some work has been done in JUnit4 in order to avoid issues with programmatically created test suites. From other hand there is a standard Parameterized TestClassRunner, which supposely should resolve the same issue, but it seems like there is still some gap. I think the problem is that @Parameters annotation require method to return Collection instance and because of that order is not guaranteed, so runner would have to keep instance of the Runner created for given params and this runner can't be recreated using index or reliable reference to parameters Collection. Anyways, erich, please reassign this bug to the right person. Thanks.
Created attachment 42108 [details] JUnit4 runner UI when running test with Parameterized runner I wonder what is the reason for those subnodes? Look really weird and unnecessarily take screen space...
moving back to inbox
Eugene, can we use this bug to capture the last issue you brought up regarding the rendering of parameterized types? We have no plans for a 'test navigator'. Running a selection and setting a breakpoint in a test are good ideas which we should look into. Do you want to create new bugs for them? (or I can)
(In reply to comment #7) > Eugene, can we use this bug to capture the last issue you brought up regarding > the rendering of parameterized types? Sure thing. Please do. > We have no plans for a 'test navigator'. It is probably worth to mention that this feature is already covered by Mylar in some level... > Running a selection and setting a breakpoint in a test are good ideas which we > should look into. Do you want to create new bugs for them? (or I can) Please go ahead if you have time. It will take me a while... If you do, please add me to cc. Thanks
Hi experts, I'm also having trouble with re-running particular tests within a test suite that manages some environmental test configuration (different network connections, different databases, etc...). All the state of an instance of a test class gets lost after execution. Since the instances are always reflectively re-created and have no dependency on the suite that originally created them I effectively can't re-run particular test cases ;-( I'm using Junit 3.8.x. Do you know of any special trick? Cheers /Eike
