Run a single JUnit test method in Eclipse

Normally you would run all JUnit tests to ensure that changes haven’t broken any of the tests. But sometimes you want to focus on a single test method and only rerun that test, especially if running all tests is too slow or if you write a single (failing) test upfront.

For example, in the following code you might only want to run testMethod2():

public class SomeTest {
   @Test
   public void testMethod1() {...}

   @Test
   public void testMethod2() {...}
}

Eclipse provides a couple of ways to run individual test methods, one from within the editor itself and another from the JUnit view. It also has especially good keyboard support so you can run those tests without reaching for the mouse.

Skip over certain classes when using Step Into in Eclipse’s debugger

Whenever I use the Step Into feature (F5) in Eclipse’s debugger, I’m mainly interested in stepping through code in my own classes, not the ones from external libraries or even Java classes.

For example, there’s almost no reason to ever want to step into Spring’s code or proxy classes (other than to learn more about them or maybe debug a potential bug in Spring). And normally I’m not interested in Java util classes (eg. ArrayList). This also goes for Hibernate, Apache Commons, Google and many other external libraries.

Fortunately, Eclipse makes it easy to specify which classes to skip by allowing step filters. This makes it easier to focus on your own code and also keeps your editor area clean since Eclipse won’t be opening classes in separate editors all the time.

Always run/debug the last launched class instead of the selected one in Eclipse

I previously mentioned shortcuts to run/debug a class as a Java app/JUnit test. But have you ever tried to rerun the last application you launched in Eclipse using F11 or the toolbar, only to find out it’s running the currently active class or selection in Package Explorer? Well, that’s because Eclipse’s default is to run the selected resource or active editor if it’s launchable (eg. if it has a main method or is a JUnit test).

Luckily, there is a preference you can change to force Eclipse to always run the last application you launched. So now you can avoid the confusion and rest assured that it’ll do what you want it to do.

Run/debug a class in Eclipse as a JUnit test or Java app with a single keystroke

If you’ve used Eclipse for a while, you may have run into the commands Run As and Debug As. These are used to launch a class/project as a particular application, eg. a Java application, JUnit test or Eclipse application.

They’re normally accessed with the mouse via the right-click menu or the pulldown menu on the run/debug icons in the toolbar. However, using the mouse to launch these classes isn’t the fastest way of doing things, especially if you’re frequently running different classes, such as JUnit tests.

To help with this, Eclipse has keyboard shortcuts to invoke the Run As/Debug As commands. They really speed up launching apps (which you’ll do often in a day’s work). I’ll show you these shortcuts and also a couple of others to make life easier.

Setup Eclipse breakpoints to stop only under certain conditions

Sometimes while debugging, you may have wanted to stop at a breakpoint only when a certain condition applies. To do this you may have used following coding pattern:

public void doSomething(Message message) {
    if (message == null) {
    	System.out.println("message is null");
    }

    // Do something with message that doesn't handle nulls well, eg...
    if (message.isFormatted() {
        //...
    }
}

It turns out lines 2-4 are temporary lines that will be removed later. They are only required for debugging so you can set a breakpoint on line 3. Although effective, this approach has its drawbacks. Firstly, you’re adding temporary code to production code and have to remember to remove it before checking in the eventual fix. Another problem arises if you want to stop only after a method has been called n times. You can introduce counting code but you’re stuck with the same problem as before.

There’s an Eclipse feature called conditional breakpoints that makes this a lot easier. The condition is attached to the breakpoint so doesn’t interfere with existing code and you can stop conditionally after a number of calls.