views:

160

answers:

4

I've been working on a Java application where I have to use JUnit for testing. I am learning it as I go. So far I find it to be useful, especially when used in conjunction with the Eclipse JUnit plugin.

After playing around a bit, I developed a consistent method for building my unit tests for functions with no return values. I wanted to share it here and ask others to comment. Do you have any suggested improvements or alternative ways to accomplish the same goal?

Common Return Values

First, there's an enumeration which is used to store values representing test outcomes.

public enum UnitTestReturnValues
{
    noException,
    unexpectedException
    // etc...
}

Generalized Test

Let's say a unit test is being written for:

public class SomeClass
{
    public void targetFunction (int x, int y)
    {
        // ...
    }
}

The JUnit test class would be created:

import junit.framework.TestCase;
public class TestSomeClass extends TestCase
{
    // ...
}

Within this class, I create a function which is used for every call to the target function being tested. It catches all exceptions and returns a message based on the outcome. For example:

public class TestSomeClass extends TestCase
{
    private UnitTestReturnValues callTargetFunction (int x, int y)
    {
        UnitTestReturnValues outcome = UnitTestReturnValues.noException;
        SomeClass testObj = new SomeClass ();
        try
        {
            testObj.targetFunction (x, y);
        }
        catch (Exception e)
        {
            UnitTestReturnValues.unexpectedException;
        }
        return outcome;
    }
}

JUnit Tests

Functions called by JUnit begin with a lowercase "test" in the function name, and they fail at the first failed assertion. To run multiple tests on the targetFunction above, it would be written as:

public class TestSomeClass extends TestCase
{
    public void testTargetFunctionNegatives ()
    {
        assertEquals (
            callTargetFunction (-1, -1),
            UnitTestReturnValues.noException);
    }

    public void testTargetFunctionZeros ()
    {
        assertEquals (
            callTargetFunction (0, 0),
            UnitTestReturnValues.noException);
    }

    // and so on...
}

Please let me know if you have any suggestions or improvements. Keep in mind that I am in the process of learning how to use JUnit, so I'm sure there are existing tools available that might make this process easier. Thanks!

+1  A: 

Looks like you reimplemented most of JUnit :) In general you don't need to do it. You just call the function you want to call and compare results. If it throws an exception, JUnit will catch if for you and fail the test. If you expect an exception, either you can use the explicit annotation if you are using JUnit 4, or you can use the following pattern:

public void testThrows()
{
    try {
        obj.DoSth(); //this should throw MyException
        assertFail("Expected exception");
    } catch (MyException e) {
        //assert the message etc
    }
}

again, if obj.DoSth() throws a different exception JUnit will fail the test.

So to sum up, I am afraid I believe your approach is overcomplicated, sorry.

Grzenio
+2  A: 

If you have the possibility, you should upgrade to JUnit 4.x.

Then your first example can be rewritten to:

@Test(expected=RuntimeException.class)
public void testTargetFunction() {
   testObj.targetFunction (x, y);
}

The advantage here is that you can remove you the private UnitTestReturnValues callTargetFunction (int x, int y) method and use JUnit's built in support for expecting exceptions.

You should also test for specific exceptions instead.

Espen
+2  A: 

It is true that if you are using JUnit 3, and you are testing whether a particular exception is thrown or not thrown within a method, you will need to use something like the try-catch pattern you define above.

However:

1) I'd argue that there is a lot more to testing a method with a void return value then checking for exceptions: is your method making the correct calls to (presumably mocked) dependencies; does it behave differently when the class is initialized with a different context or different sets of dependencies, etc. By wrapping all calls to that method, you make it hard to change other aspects of your test.

I'm also generally opposed to adding code and adding complexity if it can be avoided; I don't think it's a burden to have to put a try/catch in a given test when it's checking for exceptions.

2) Switch to JUnit 4! It makes it easy to check for expected exceptions:

@Test(expected=IndexOutOfBoundsException.class)
public void testIndexOutOfBoundsException() {
    ArrayList emptyList = new ArrayList();
    Object o = emptyList.get(0);
}
JacobM
I've rewritten my tests to use this format. It's much easier. Thanks!
RobotNerd
Be aware that if you use this syntax, the test will pass if any of the code running in the test threw IndexOutOfBoundsException. Sometimes that isn't a problem, since you already have test cases that cover the non-exceptional cases, but don't do this for long tests. If you use JUnit 4.7. try the ExpectedException Rule: http://www.infoq.com/news/2009/07/junit-4.7-rules
NamshubWriter
A: 

Hi,

please correct me if I am wrong. As I understood from the provided code you're only checking if there may be an exception while executing the function. But you're actually not verifying, if the called functions "works" correctly unless the only way to end in case of an error would be an exception. I suggest writing additional tests like this:

public void testTargetFunctionSomeValue()  {
  int someValue = 0;
  callTargetFunction(someValue, someValue);
  assertTrue(verifyTargetFunction(someValue, someValue));
}

public boolean verifyTargetFucntion(int someValue, int someValue) {
 // verify that execution of targetFunction made expected changes.
  . . . . . 
}

and the verifyTargetFunction would acutally check, if calling targetFunction would have made the expected changes - let's say to a database table by returning true or false.

Hope that helps.

Cheers, Markus

Markus Maria Miedaner