Working Efficiently with JUnit in Eclipse

Home  >>  Eclipse  >>  Working Efficiently with JUnit in Eclipse

Working Efficiently with JUnit in Eclipse

On November 26, 2012, Posted by , In Eclipse,JUnit, By ,,,, , With 11 Comments

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.

See also  Efficient Creation of Eclipse Modules with Maven Archetype

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).

 Testing with JUnit

Testing with JUnit Book

Testing with JUnit is one of the most valuable skills a Java developer can learn. No matter what your specific background, whether you’re simply interested in building up a safety net to reduce regressions of your desktop application or in improving your server-side reliability based on robust and reusable components, unit testing is the way to go.

Frank has written a book that gives a profound entry point in the essentials of testing with JUnit and prepares you for test-related daily work challenges.

  Get It Now! 

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:

See also  How to Clone Git Repositories with JGit

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.


  1. The discussion happened during one of those spontaneous couple-of-beers-after-work-sessions we like to have once in a while…
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. There are even tools available that run your tests continuously.
  7. In practice I often use the Ctrl+F7 shortcut to switch to and/or between view parts.
Frank Appel
Follow me
Latest posts by Frank Appel (see all)

11 Comments so far:

  1. Pascal Rapicault says:

    An additional trick that I use consists in right clicking on a failed test to have it be re-run.

  2. Eric Jablow says:

    I tried to create a set of templates for a @RunWith(Parameterized.class) test and its @Parameters method. That would be useful, but I’m not sure I did those right.

    Similarly, there could be specialized templates for assertThat and Hamcrest matchers, ans dome could even auto-import a set of matchers. Remember that JUnit 4.11 stripped its miniature version of Hamcrest out and uses the full version.

    Finally, there could be templates for the various JUnit @Rules. The string ‘ee’ at top-level on a test class could expand to:
    public @Rule ExpectedException thrown = ExpectedException.none();

  3. jotomo says:

    For people prefering the keyboard and shortcut over the mouse I’d recommend MoreUnit (http://moreunit.sourceforge.net/). It defines shortcuts to switch between the test and the class under test, another shortcut to use when editing a class which will find the correspending test and run it. Furthermore, it decorates classes in the navigator, indicating they have a test. It also helps quickly creating a test for a class in the right place and extends the rename refactoring to rename the test class to be in sync with the renamed class.
    No, I’m not involved with MoreUnit, I just like how comfortable I can quickly run tests with it :-)

  4. Peter Kofler says:

    Excellent collection of JUnit related tips and shortcuts. Thank you.

  5. mestachs says:

    Thanks for the unknown shortcuts ;)
    My 2 cent contribution

  6. Frank Appel says:

    Thanks for the nice comments. And I will definitively check MoreUnit – sounds promising :-)

  7. Jimmy says:

    I would like to add that since older Eclipse versions come with older Junit versions, many new features are un-explored. It is possible to change the Junit version. This essentially helps in using the newer Junit features like rules, parameterized test cases etc.

  8. Anton says:

    Wow, the favorites part was great tip for me! Added Mockito base and Matchers immediately!