< Zurück | Inhalt | Weiter >

13.5.1 JUnit Assertions

These are the various test assertions available with JUnit:

assertEquals(), comparing

boolean with boolean

char with char

short with short

int with int

long with long

float with float

double with double

Object with Object

String with String


assertTrue( boolean expression )

assertFalse( boolean expression )

assertNull (Object)

assertNotNull (Object)

assertSame (Object1, Object2)

assertNotSame (Object1, Object2)

fail()

Each of the assert methods comes in two “flavors,” one with a message String and one without. For example, there is a method assertTrue() which takes a boolean as its parameter; typically it would be used with an expression, for example:1


assertTrue( (sample actual) );


If the condition is not true, an AssertionFailedError is thrown. That means, among other things, that if/when your test fails, it will stop executing at that point. The tearDown() method, though, will still be executed before proceeding to the next test.

There is also a method of the same name, assertTrue(), but with a slightly different signature—it adds a String as its first parameter. The string is the message to be included in the error report. Using this variation on assertTrue(), our example would become:


assertTrue("Sample too small", (sample actual));


In the same way, assertFalse() has two versions— assertFalse(boolean) and assertFalse(String, boolean)—and so on for all other assert methods.


image

1. Yes, the extra parentheses are not needed; they just make the point that this is a boolean ex- pression being passed as the argument to assertTrue(). We could also have written it as:

boolean result = (sample actual); assertTrue(result);

Again, the extra parentheses are used just to make it clearer.


image

The String message is very helpful when you get large numbers of com- parisons and assertions inside your test cases. It can help you identify which assert in which test failed.



TIP

When writing your assertions, keep in mind the difference between assertEquals() and assertSame(). The latter will test if the two argu- ments refer to the very same instance of an object, whereas the former only checks to see that their values are equal. So any two references to objects that are the same will also be equal, but not vice versa. For example:


String sample = "value";

String others = "more value".substring(5); assertEquals(sample, others); // will pass assertSame(sample, others); // will fail


Digging a little deeper into how all this works, it might be worth pointing out that the JUnit TestCase class, while an abstract class itself, is also an exten- sion of another class, the Assert class. The Assert class is the class that defines all these public static methods for asserting the various conditions (see the list above). That is why you don’t need any qualifiers on the various assert calls. They are all part of your test case by virtue of it extending TestCase. It also means that you could override any of them to get special behavior. This might be useful for assertEquals(Object, Object), to allow you to compare objects of your own kinds, but we don’t recommend this. You are better off overriding the equals() method of your own object than messing with the JUnit methods. And remember that if you override those behaviors, your tests will only be as good as your implementation of the assert mechanisms.