Using catch-exception in JUnit Tests

I use ExpectedException a lot in my JUnit test to verify exceptions thrown. In some circumstances, you would also want to run some assertions in the tests after the exception is thrown. This is impossible with ExpectedException. In this post, I will demonstrate how to use catch-exception instead to achieve this.

Set up

Let say we have the following class we want to test:

public class MyService {

 private MyDao dao;
 public MyService(MyDao dao) {
      this.dao = dao;
 public void someMethod() {
      // Some codes here. Throw an exception for demo purpose
      if (true) {
           throw new NullPointerException("NPE!");

Note the method someMethod() will throw an NullPointerException. This simulates real codes that throws an exception when the object in certain state or when one of the methods it calls within returns with an exception.


ExpectedException works by wrapping the entire test method by its own try-catch block. As a result, any assertion statements after the method that throws the exception are not called.

public class MyTest {

 public ExpectedException none = ExpectedException.none();
 public void testUsingExpectedException() {
      MyDao mockDao = mock(MyDao.class);
      MyService service = new MyService(mockDao);
      // Note the following line is not called. Test still passes

Note the test above verifies that the NPE is thrown as expected. The dao’s afterException method is never called and the test will still pass.


Catch-exception is a library that would address the issue above with ExpectedException. To use it, include the following Maven dependency

      <scope>test</scope> <!-- test scope to use it only in tests -->

and update the test as follows

 public void testUsingCatchException() {
      MyDao mockDao = mock(MyDao.class);
      MyService service = new MyService(mockDao);
      // Hamcrest
      assertThat(caughtException(), instanceOf(NullPointerException.class));
      // Mockito verify got called
      verify(mockDao, never()).afterException();

Now the assertion (mockito verify) statements are called. This could be useful if you want to verify that the object is in the correct state or as in the example certain methods of the object’s member is (not) called when the method throws an exception.

Writing parameterized Tests with Spring and JUnit 4

This blog will demonstrate how to write parameterized tests with JUnit4 with Spring.

Let say we have the following interface

public interface Logic {
     boolean xor(boolean a, boolean b);

and the corresponding implementation annotated as a Spring service component

public class LogicImpl implements Logic {
      public boolean xor(boolean a, boolean b) {
            return a ^ b;

To test the above class with different input combinations of arguments a and b, we can write the following parameterized test in JUnit

@RunWith(Parameterized.class) // Note 1
@SpringApplicationConfiguration(classes = BlogApplication.class)
public class LogicImplTest {

     private LogicImpl logic;

     // Manually config for spring to use Parameterised
     private TestContextManager testContextManager;

     @Parameter(value = 0) // Note 3i
     public boolean a;

     @Parameter(value = 1) // Note 3ii
     public boolean b;

     @Parameter(value = 2) // Note 3iii
     public boolean expected;

     @Parameters // Note 4
     public static Collection<Object[]> data() {
          Collection<Object[]> params = new ArrayList<>();
          params.add(new Object[] { true, true, false});
          params.add(new Object[] { true, false, true});
          params.add(new Object[] { false, true, true});
          params.add(new Object[] { false, false, false});

          return params;

     @Before // Note 2
     public void setUp() throws Exception {
          this.testContextManager = new TestContextManager(getClass());

     @Test // Note 5
     public void testXor() {
          assertThat(logic.xor(a, b), equalTo(expected));


A few things to note here:

  1. The test class is to be run with the Parameterized runner, instead of the normal SpringJUnit4ClassRunner class.
  2. We need to manually configure the test context manager as in the @Before method. This is typically done automatically by Spring
  3. Parameters are defined as public members of the class (as in 3i to 3iii) with the @Parameter annotation. Since we have more than 1 parameter, it is also neccessary to set the value attribute. This defines the index of the parameters to use.
  4. Parameter values are set by implementing a static  method and annotate it with @Parameters. In our example, the data() method returns a list of object arrays. Each value of the list params corresponds to a set of parameter values.
  5.  Tests now can use the parameter values.

Running the test class in Eclipse will give you something like this


Note testXor() is run 4 times, each using the parameter set of the values defined in the list returned by the data() method.


Capture screenshots when Selenium tests fail

This blog continues on my last blog on Selenium and demonstrates how to setup Junit4 to capture screenshots of the browser when  tests fail.

Create JUnit Rule

First, the rule in which JUnit uses to run and report test methods needs to be updated. This is done by implementing the interface org.junit.rules.MethodRule. JUnit provides a base class TestWatchman where we can extend:

public class ScreenShotRule extends TestWatchman {

 public void failed(Throwable e, FrameworkMethod method) {
 // capture screenshot here

Capture screenshots with Selenium

Selenium WebDriver implements the interface TakesScreenshot which indicates the web driver has the capability to capture screenshots. To enable this, the RemoteWebDriver instance needs to be augmented as below.

// In class AbstractRCTest (see my previous blog)
driver = new RemoteWebDriver(remoteUrl, capabilities);

 // Augment web driver for screenshot capture
 WebDriver augmentedDriver = new Augmenter().augment(driver);
 screenShotRule = new ScreenShotRule(augmentedDriver);

Now we can implement screenshot capture in class ScreenShotRule to take screenshots with Selenium and save it to file:

 public void failed(Throwable e, FrameworkMethod method) {
      File scrFile = ((TakesScreenshot) webdriver).getScreenshotAs(
      String scrFilename = method.getName() + "-Screenshot.png";
      File outputFile = new File("C:\\Temp", scrFilename);
      try {
           FileUtils.copyFile(scrFile, outputFile);
      } catch (IOException ioe) {
           log.error("Error copying screenshot after exception.", ioe);

Add rule to JUnit test class

Last thing to do is to set new rule in the unit test class

public class SampleRemoteTest {
     public ScreenShotRule screenShotRule;

That’s it. Now if a test fails, a screenshot will be taken of the browser in the server machine and saved into a local client where the test is run.

Testing with ActiveMQ embedded broker


This blog demonstrates what you may do to setup and run tests for a JMS message system using ActiveMQ’s embeeded broker. In general, you should focus on testing on your message producers and consumers. However you may also find it useful in some circumstances to write some integration tests to make sure that the various components of the message system are implemented correctly.

Setup ActiveMQ embedded broker

This section shows how to setup a embedded broker in ActiveMQ using an ActiveMQConnectionFactory. First, you need to create a BrokerService instance:

    protected BrokerService createBroker() throws Exception {
        BrokerService service = new BrokerService();

        // Setup policy

        connector = service.addConnector(""tcp://localhost:61616");
        return service;

It may be useful to setup the broker policy to match your system setup. For example, to configure broker to wait for consumers before dispatching starts, insert the following codes after “// Setup policy” comment above:

        PolicyMap policyMap = new PolicyMap();
        PolicyEntry policy = new PolicyEntry();

Now to create embedded broker using connection factroy:

        ActiveMQConnectionFactory connFactory = 
                  new ActiveMQConnectionFactory(connector.getConnectUri() 
                                           + "?jms.prefetchPolicy.all=1");
        connection = connFactory.createConnection();

Now we are ready to start the broker. I put the codes altogether into an abstract class for JUnit:

@ContextConfiguration(locations = { "/spring/app-root-test.xml" })
public abstract class AbstractActiveMQJMSTest {

    protected Connection connection;
    protected BrokerService broker;
    protected TransportConnector connector;
    protected int consumersBeforeDispatchStarts;
    protected int timeBeforeDispatchStarts;

    private String brokerUrl;

    public void setUp() throws Exception {
        broker = createBroker();
        ActiveMQConnectionFactory connFactory = 
              new ActiveMQConnectionFactory(connector.getConnectUri() 
                                       + "?jms.prefetchPolicy.all=1");
        connection = connFactory.createConnection();

    public void tearDown() throws Exception {

    protected BrokerService createBroker() throws Exception {
       ... // omitted to save space. See codes above

Writing Tests

Writing tests using the above abstract class is straight forward. For example, the codes below demonstrate how to test that all messages from a producer are dispatched to the same consumer (i.e. exclusive consumer). Note this is a make-up test case for the purpose of demonstrating how a unit test can be written and run using the embedded broker in ActiveMQ. In practice you would only need to write unit tests to check message headers are setup properly in the producer to ensure exclusive customer feature is setup correctly.

public class ExclusiveCustomerMessagingTest extends AbstractActiveMQJMSTest {

    private ISomeProvider provider;

    public void testStickyConsumer() throws Exception {
        for (int i = 0; i < 5; i++) {

        // now create some consumers
        CountDownLatch startSignal = new CountDownLatch(1);
        CountDownLatch doneSignal = new CountDownLatch(1);

        Destination dest = new ActiveMQQueue("foo-queue");
        MessageConsumerGroupThread worker = 
             new MessageConsumerGroupThread(connection, dest, "foo", 
                                        startSignal, doneSignal, 5);

        MessageConsumerGroupThread worker2 = 
             new MessageConsumerGroupThread(connection, dest, "foo2",
                                         startSignal, doneSignal, 5);

        Thread workerThread = new Thread(worker);
        Thread workerThread2 = new Thread(worker2);

        doneSignal.await(); // this blocks until workers are done

        List<Message> msg = worker.getMessagesReceived();
        List<Message> msg2 = worker2.getMessagesReceived();

        // Test sticky customer
        assertEquals(5, msg.size() + msg2.size());
        assertTrue(msg2.size() == 5 || msg.size() == 5);


Note MessageConsumerGroupThread class implements Runnable and loops until a prescribed number of messages (5) from the destination have been handled by the internal message consumer or being stopped by the calling test method.


  1. ActiveMQ documentation on the differnt approaches one can use to create an embedded broker.
  2. ActiveMQ javadoc API.