Recently I was dragged into a discussion1 with some test infected2 fellows about how we use JUnit within the Eclipse IDE. Surprisingly the conversation brought up some ‘tips and tricks’ not everybody was aware of. This gave me the idea to write this post doing a sum up of our talk. Who knows – maybe there is something new for somebody out there too…
Launch Shortcuts
If you are doing Test Driven Development you have to run your tests quite often. Obviously it gets somewhat tedious using e.g. the context menu of the editor to select the Run As -> JUnit Test to launch a test case under development. Fortunately the shortcut Alt+Shift+X,T does the same and Alt+Shift+D,T executes the test in debug mode. But there is more in that than meets the eye.
Consider the following situation: a unit under test does not work as expected anymore. You have recognized this because a certain test of your test suite fails. Having a look at the code might not be conclusive so you decide to start a debugging session. To do so you set a breakpoint at the current cursor position (Ctrl+Shift+B). In such a case you are probably not interested in re-running the suite or even all the tests of the given test class. You only want to launch the single failing test3.
Now it is important to know that the ‘Run as’ shortcuts described above are sensitive to the editor’s cursor position. Moving the cursor to a test method name allows to use those shortcuts to launch a JUnit process that runs this test method only45.
Carrying on the example a little bit it is very likely that you will find a suspicious spot in your unit under test during the debugging session. Considering a solution you might change some code of that unit. After that you want to see if the test method still fails. Luckily there is another shortcut in Eclipse that allows you to re-run the latest executed launch configuration.
Use F11 to re-run your debug session and Ctrl-F11 to re-run the test method normally. However there is a preference setting that have to be set to make this work reliable. After opening the Launching preference page (Windows -> Preferences | Run/Debug -> Launching) there is a section called Launch Operation. Ensure that the Always launch the previously launched application radio button is selected.
Method Templates
Every time you are about to create a new test method you might consider using Eclipse editor templates to improve your coding efficiency. Once you have positioned the cursor at the location where the new test method should be located type test and hit the Ctrl+Space shortcut to pop up the content assist.
As shown in the first part of the picture above the content assist offers a test method template that will create a complete method stub on selection. Unfortunately this would be a JUnit 3 style method stub. But hitting Ctrl+Space again will reveal a second template that is written in JUnit 4 style. This is shown in the second part of the picture above.
In spite of all hitting the shortcut twice still seems to be too cumbersome for many developers. And writing test cases you often have to create setup and/or teardown methods annotated with the @Before/@After tag as well. But thankfully it is possible to provide your own editor templates in Eclipse. Holger Staudacher has written a good post called Simple JUnit4 templates for Eclipse where he explains how to do this and even provides a set of templates in a gist.
Favorites
JUnit tests rely heavily on the usage of the various assertXXX methods provided by the class junit.framework.Assert. Those methods are all declared as static and can be referred to as Assert.assertTrue(condition) for example. But as far as I know most people would use static imports to shorten the statement for the sake of readability to assertTrue(condition).
But by default the IDE’s content assist will not suggest the static methods of the Assert class. One way to get around this is to write the class name and let the content assist propose the available methods. The latter might be accelerated by using camel case matching. After that the use of Ctrl+Shift+M as described in Rüdiger’s post about static import shortens the statement and generates the import.
However I think the most efficient way is to configure the junit.framework.Assert class as content assist favorite to allow the proposal of the static members even if the import is still missing. The configuration takes place in (window -> Preferences | Java -> Editor -> Content Assist -> Favorites) and looks like this:
JUnit View Configuration
While working test driven running your tests regularly gets practically organic 6. However running a larger test suite takes some time. In the meanwhile the JUnit View pops up and continously updates the list of test results. But this can get enervating as it is distracting in the best – or even obstructing your work in the worst case.
With test driven development you expect your tests to succeed at a rate of 100%. And because of this many developers want to be informed about failing tests only – the exception of the rule. The JUnit view supports this with a configuration setting called Activate on Error/Failure Only available via the viewpart’s menu:
Every now and then your test suite will fail and there may be more than one problem at once. By default the JUnit view lists all test results. But as a developer you’re generally more interested in the failing ones and may percive the bulk of green tests as clutter. Here focus on your work means focus on the failing tests. There is a configuration setting called Show Failures Only available to change this behaviour. As people tend to change this setting more frequently a toggle button in the viewpart’s toolbar is provided.
Fast View
If your are working with Eclipse 3.x there is a nice feature called Fast View that allows to unclutter your UI a bit. In general I prefer this for views that I use regularly but not continously and/or for views that I consider more lucid if provided with more space. Examples for this might be the Coverage-, History- or the Call Hierarchy view. A viewpart tab provides a content menu that makes it possible to use a view as fast view:
This removes the view from its stack and shows a toggle button in the fast view toolbar at the left bottom corner of your workbench. With this button you can activate/deactivate a particular view as overlay7:
A specific feature of the JUnit fast view button is that it provides status info about the latest test run or progress info about a currently executed one. So this little button is all the UI you need for a good deal of the time you spent with JUnit:
Unfortunately fast views are no longer available in Eclipse 4.x. But there is a workaround that meets the behavior to a certain degree. You can move the views you want to use as ‘fast views’ into a designated view stack and minimize this stack. The toolbar representing the minimized view stack now serves as the former fast view bar. This works so-so as the activation/deactivation sometimes hangs and you have to fiddle a bit to hide the view and get back to the editor for example.
In essence I think the sections above are covering the main points we were talking about in the disscussion I mentioned at the beginning of this post. Maybe you also have some infos about useful JUnit shortcuts, using patterns or the like to share – feel welcome to add a comment.
- The discussion happened during one of those spontaneous couple-of-beers-after-work-sessions we like to have once in a while…
- It is said that the term ‘test infected’ was originally coined by Erich Gamma. Together with Kent Beck he also published an article called JUnit Test Infected: Programmers Love Writing Tests that describes how ‘your attitude toward development is likely to change’, once you drive your programming work consistently with tests.
- In particular if a breakpoint is not located in the test method as in the example but in the unit under test it can get annoying running all test methods of a test case. This is because the program execution might halt at the breakpoint triggered actually by one of the test methods that do not have a problem.
- Unfortunately the framework is not able to distinguish test methods from non test methods. Using the shortcut on non test methods will lead to JUnit runs that show an Unrooted Tests error as result.
- Some of the attendees considered it as a minor downside that the framework automatically creates and persists launch configurations. Because of this behaviour running single test methods via shortcuts can generate a lot of clutter in your launch configuration list over time.
- There are even tools available that run your tests continuously.
- In practice I often use the
Ctrl+F7shortcut to switch to and/or between view parts.
Reference: Working Efficiently with JUnit in Eclipse from our JCG partner Frank Appel at the Code Affine blog.
