Writing Effective Tests
From Software By Jeff
On topic of much debate is how to write an effective JUnit test. Unit testing is new to many people, and often the impulse to write as little code as necessary is overwhelming, resulting in poor test implementation. Consider this code snippet.
public void testSomething(){
SomeClass.someMethod();
}
Before wondering why such a simple test is used as an example, consider that this was taken from a real test class I saw, changing the names as they'd otherwise be irrelevant here.
What exactly does this test? Well, it makes certain that a class named SomeClass is in the class path, and that it contains a static method named someMethod() that takes no parameters, as missing any of these would cause compile failures. One could argue that it also tests that the method does not throw an Exception when executed, as that would cause a runtime failure, but that's not evident by the declaration of the test.
Thus, based on the test, this is all that we know we have:
public class SomeClass{
public static void someMethod() {}
}
And, using Test Driven Development, that should be all that is there. If we want more, we need to have a better test or set of tests.
Since our method is obviously static, the items it affects are likewise static, or short lived and internal completely to someMethod(). Does this mean there's nothing to test? Absolutely not. It just might be harder than some.
Let's not dally with the obvious headaches of dealing with static methods. See the discussion Testing Static Members and Methods for information on how to get to the things a static method might affect.
Useful Methods
We can assume that when we write code we want to make useful bits along the way. Therefore, we should be right in assuming that someMethod() does something useful. However, as written, nothing is tested.
When we write our useful methods, it is almost certain that our object is in some state before we begin, and it is in a different state when we finish, or that it thusly affects some other object. The appropriate test should check the state before and after the method call, and ensure the anticipated change is made.
Changing State =
Here's an example of a more useful, yet still simple, test.
public void testSomethingUseful(){
SomeClass someClass = new SomeClass();
int originalValue = someClass.getCount();
someClass.someMethod();
assertEquals(originalValue + 1, someClass.getCount());
}
There's a bit of a better test. In this test, we can infer that someMethod is going to affect the int value that getCount() will return, apparently incrementing the integer by one.
Very simple and straight forward. We get the value before we do the work, do the work, and compare the value with expected results. How does our class look now?
public class SomeClass{
private static int count = 0;
public static void someMethod() {
count++;
}
public int getCount() {
return count;
}
}
That is all our test tells us to expect, so that's all we can infer about the methods.
Note, we had to take the liberty of assigning count with an initial value. Nothing in our test says this has to be zero. Perhaps another test would be in order to ensure the creation is zero. Since it's static, though, testing this can be difficult as we can't be certain that we're always the first test affecting this class.
Writing test does not have to be cryptic by any means. A very simple rule of a test should test something should be followed no matter what the test is for. If all you're doing is asserting a class name and method, we can hope that the next line of the test is more important.