The same, but different

2008-09-05T23:16:00.001-07:00

Recently I’ve been using JUnit. In keeping with the most up to date libraries, we upgraded our project this week to JUnit 4.4 to JUnit 4.5 and that’s where we encountered a hiccup….

In our project, we are interested in doing specific things if a test has failed. For the purposes of demonstration, lets suppose that we want to output the test name to the console when a test fails (using a method annotated with @After). How do we know whether a test has failed or not? We can access this information by using a custom test runner that extends the JUnit4ClassRunner (in JUnit 4.4), like this one ...

public class MyTestRunner
extends JUnit4ClassRunner
{
private static String
 failureMessage = null;

public static String getFailureMessage() {
 return failureMessage;
}

public MyTestRunner(Class klass)
 throws InitializationError
{
 super(klass);
}

public void run(final RunNotifier notifier) {
 failureMessage = "";
 notifier.addListener(new FailureListener());
 super.run(notifier);
}

private class FailureListener
 extends RunListener {

 public void testFailure
    (Failure failure) throws Exception {
    failureMessage = failure.getTestHeader();
 }
}
}

Our runner (above) overrides the run method (only) so that we can add a FailureListener to the RunNotifier. As per the observer pattern, our notifier will call the testFailure method if the test fails, thereby setting the failureMessage. We can access the failure message from our @After method like this...

@RunWith(MyTestRunner.class)
public class MyClassTest
{
@After
public void printRunStatusMessage()
{
if (!MyTestRunner.getFailureMessage().equals(""))
 System.out.println(MyTestRunner.getFailureMessage());
else
 System.out.println("Test did not fail");
}

@Test
public void shouldAssertTruth() throws Exception
{
assertEquals(true, false);
}
}

Note that our test class is annotated with @RunWith(MyTestRunner.class) - meaning that we are running the tests using our custom runner. If we go ahead and run the shouldAssertTruth test we get this line printing to the console "shouldAssertTruth(com.thoughtworks.blogdemo.test.MyClassTest)". Ta da!

In the migration to JUnit 4.5, we discovered that JUnit4ClassRunner is now deprecated. It has been replaced with the new BlockJUnit4ClassRunner. According to the JUnit API documentation the BlockJunit4ClassRunner "should have exactly the same behavior as the old test class runner (JUnit4ClassRunner)". By simply substituting the old runner class with the new one and re-executing the shouldAssertTruth test we get (drumroll) "Test did not fail" output to the console... hmm, that's not expected....

In JUnit 4.4 there are calls to an addFailure method scattered throughout the code that executes the @Before, @Test and @After annotated methods for each test. This is what the addFailure method looks like:

protected void addFailure(Throwable e) {
fNotifier.fireTestFailure
 (new Failure(fDescription, e));
}

This method lets us know immediately when a test has failed and is the reason why our custom runner worked so well. In JUnit 4.5 we now have the concept of Statements, and without going into detail about them, JUnit now has a RunAfters class. This class is used when we want to run a test and execute its associated @After methods. The class looks like this...

public class RunAfters extends Statement {
private final Statement fNext;
private final Object fTarget;
private final List fAfters;

public RunAfters(Statement next,
   List afters,
   Object target) {
fNext= next;
fAfters= afters;
fTarget= target;
}

@Override
public void evaluate() throws Throwable {
List fErrors = new ArrayList();
fErrors.clear();
try {
  fNext.evaluate();
} catch (Throwable e) {
fErrors.add(e);
} finally {
  for (FrameworkMethod each : fAfters)
try {
    each.invokeExplosively(fTarget);
  } catch (Throwable e) {
fErrors.add(e);
}
}
if (fErrors.isEmpty())
  return;
if (fErrors.size() == 1)
  throw fErrors.get(0);
throw new MultipleFailureException(fErrors);
}
}

We can see in the evaluate method that any errors that are thrown during the executing of the test are collected in fErrors. fErrors is used at the end of the evaluate method to create and throw a new MultipleFailureException, which will notify our FailureListener. The crucial part for us is that despite an error being thrown during the execution of a test, the @After method will always be attempted in the finally block, and at that point we are blissfully unaware that the test has failed. Hmph.

Our solution, the quickest one to restore functionality (and not use anything deprecated), has been to create a custom RunAfters class that notifies our FailureListener of any errors in the catch block (see above). It seems less than ideal to have to do this, especially since the changes to the RunAfters class are so minor. Perhaps the next JUnit version will do something else...

Small things amuse small…. hmph, well anyway….

2008-08-30T22:09:00.000-07:00

My first four months in the software industry has been a really exciting challenge. There is a lot to get up to speed with and it’s changing all the time. One thing that really impresses me about the people that I get to work with is that they are all eager to learn, as am I. What is a little daunting is that I often find myself in conversations where I know absolutely nothing about the technology that the other person is talking about(!), simply because I haven’t been exposed to it before. For the most part though I feel like a kid in a candy store wanting to get my sticky little fingers into all the amazing colourful jars.

Two things that I’ve recently found out about are dynamic proxies and (drum roll) pixel rulers! I did probably get a little too excited about the latter, but hey, that’s me. My colleague suggested the dynamic proxy implementation and it turned out really neat….

In our application we are reading some data from an MS Excel file. The Excel file is very simple: it has a column listing the names of parameters and an adjacent column listing the values for each of those parameters. We’re using JExcelAPI to read the parameter values. Each of the parameter names matches up to a method name on our interface, which looks something like this:


public interface Parameters
{
    String parameterA();

    String parameterB();
}

Our first attempt at providing access to the value for each parameter was:


public class ExcelParameters implements Parameters
{
    private ExcelReader reader = new ExcelReader();

    public String parameterA() {
         return reader.readParameter("parameterA");
    }

    public String parameterB() {
         return reader.readParameter("parameterB");
    }
}

Obviously this solution was neither elegant nor easy to maintain. All we were really after was a way to return the value of the parameter corresponding to the method name (which is also the parameter name) from Excel. Enter the dynamic proxy…

There is a lot of material available describing the implementation dynamic proxies in Java, including this article. Our dynamic proxy use is unconventional because, unlike in the normal use case, we never invoke the called method on an actual implementation of the Parameters interface. Instead we simply get the name of the called method and look up the corresponding parameter value in Excel:

The big advantage of this approach is that we never need an implementation of our Parameters interface – the proxy does this for us automatically. Our proxy is an implementation of the java.lang.reflect.Proxy class and looks like this:


public static Parameters getExcelRepository () {
    ClassLoader cl = Parameters.class.getClassLoader();
    Parameters proxy =
         (Parameters) Proxy.newProxyInstance(cl,
         new Class [] {Parameters.class},
         new ExcelParameterHandler());
    return proxy;
}

And the invocation handler that actually looks up the Excel sheet looks like this:


public class ExcelParameterHandler
   implements InvocationHandler
{
    private ExcelReader reader = new ExcelReader();

    public Object invoke(Object proxy,
                 Method method, Object[] args)
                 throws Exception
    {
       return reader.readParameter(method.getName());
    }
}

And here is how we can use it:


@Test
public void shouldBeAbleToReadParametersFromExcel()
  throws Exception
{
    Parameters excelParameters =
        ParameterRepository.getExcelRepository();
    assertEquals("value for ParameterA",
        excelParameters.ParameterA());
}

Voila!

Drum Roll!

The same, but different

Small things amuse small…. hmph, well anyway….