Posts Tagged junit

NetBeans 6.7 Broke My Parameterized Tests

Posted by rn in General, Java, Software Engineering on August 6th, 2009

If you had some JUnit parameterized tests with code such as:

import java.util.Collection;
import junit.framework.TestCase;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;

@RunWith(Parameterized.class)
public class MyParamTest extends TestCase {

    public MyParamTest(String s1, String s2) {
        // do something with s1 and s2
    }

    public static Collection getParams() {
        // return test parameters
    }

    public void testSomeStuff() {
        // testing testing testing
    }
}

You may have found when you upgraded to Netbeans 6.7 (with the improved JUnit test runner) that your tests suddenly started failing.

This is because any class extending TestCase is run as a regular JUnit test and so will fail if it’s actually a parameterized test. Just change the code to use the static import instead:

import java.util.Collection;
import static junit.framework.TestCase.*;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;

@RunWith(Parameterized.class)
public class MyParamTest {

    public MyParamTest(String s1, String s2) {
        // do something with s1 and s2
    }

    public static Collection getParams() {
        // return test parameters
    }

    public void testSomeStuff() {
        // testing testing testing
    }
}

Bob’s yer mother’s brother.

, , ,

No Comments

Testing Abstract Classes With Mockito and JUnit

Posted by rn in General, Java, Software Engineering on July 28th, 2009

Often times in Java, you have an abstract parent class which has some concrete methods which call abstract methods which will be implemented by the child classes.

So what’s an easy way to test this sort of pattern?

A mock is not an appropriate solution, since we don’t want to mock our abstract class, we want to provide an implemention of the abstract methods, which we can mock to test the logic of the parent class.

There is a neat solution to this problem, using the great mocking framework for Java – Mockito -

public abstract class MyAbstract {
  public String concrete() {
    return abstractMethod();
  }

  public abstract String abstractMethod();
}

public class MyAbstractImpl extends MyAbstract {
  public String abstractMethod() {
    // we have to provide an implementation that will run without error
    return null;
  }
}

public class MyAbstractTest extends TestCase {

  public void testConcrete() {
    MyAbstractImpl abstractImpl = spy(new MyAbstractImpl());
    doReturn("Blah").when(abstractImpl).abstractMethod();
    assertTrue("Blah".equals(abstractImpl.concrete()));
  }
}

So what’s going on here?

Well Mockito (1.8+) implements a “spy” feature which doesn’t mock the object, it creates a “spy” wrapper around the real method implementations. This allows us to override the return values / exception behaviour of some methods, but leave other methods to implement their usual behaviour.

In the code above, we override the abstractMethod() which is part of the implementation class, to test the concrete() method in our abstract class. Of course, usually the abstract class would be doing something more interesting than simply returning the implementor’s value, and so we would implement tests in the ususal fashion to test the different code paths in our concrete() method.

, , ,

No Comments