Pragmatic Unit Testing: single assert per test?

[Jeff Langr]

Greetings Mssrs Hunt & Thomas,
Does your book go into the debated topic of one assert per test (what I believe Mr Astels promotes)? Which camp do you fall into?
regards,
Jeff

[Lasse Koskela]

Ooh. A good one, Jeff
To speculate a little bit, I guess the pragmatic programmers don't care much about such a rule even if they would "happen" to follow such a practice. Am I right?

[Prag Dave]

We say "put as many tests in the method as makes sense!" I'm not sure I see any benefit to restricting yourself to one test per method, but at the same time I also feel strongly that each test method should address a coherent set of issues. If you're testing a search method, I'd personally test "normal" behaviors in one test method, and then exceptional behaviors in one or more separate methods. It all comes down to optimizing convenience and readability.
Cheers

Dave
[ February 17, 2004: Message edited by: Prag Dave ]

[Jeff Langr]

Originally posted by Prag Dave:
We say "put as many tests in the method as makes sense!" I'm not sure I see any benefit to restricting yourself to one test per method, but at the same time I also feel strongly that each test method should address a coherent set of issues. If you're testing a search method, I'd personally test "normal" behaviors in one test method, and then exceptional behaviors in one or more separate methods. It all comes down to optimizing convenience and readability.

If I were to try and see the side of the "one assert per test camp" (which I think also includes Jim Newkirk), it might be that the goal of pushing in that direction leads to designing methods that are better composed.
Asserts are generally postconditions. Verifying object state may require a number of postconditions, so I don't have any qualms about additional asserts. And you're right: readability can be significantly affected by too much test decomposition.
Thanks for the answer!
-Jeff-
[ February 17, 2004: Message edited by: Jeff Langr ]

[Ilja Preuss]

Another technique to reduce the number of asserts in a method is to write custom assert methods.
For example, instead of
assertEquals(2, list.size());
assertEquals("first", list.get(0));
assertEquals("second", list.get(1));
you could write
assertListEquals(new String[] {"first", "second"}, list);
or something.

[Lasse Koskela]

Originally posted by Ilja Preuss:
Another technique to reduce the number of asserts in a method is to write custom assert methods.

And sometimes it's just fine to rely on the equals() method:

public void testSomething() {
    MyObject expected = new MyObject("foobar");
    MyObject actual = ClassUnderTest.createMyObject("foobar");
    assertTrue(expected.equals(actual));
}

Of course this approach hides the actual difference between the two objects...

[Dave Thomas]

Originally posted by Jeff Langr:

If I were to try and see the side of the "one asert per test camp" (which I think also includes Jim Newkirk), it might be that the goal of pushing in that direction leads to designing methods that are better composed.

And I'd agree with this sentiment, but to me it says "one concept per test", not one assert per test.
Cheers

Dave

[Jeanne Boyarsky]

Lasse,
Why would you use
assertTrue(expected.equals(actual))
instead of
assertEquals(expected, actual) ?
If there is a toString method, assertEquals gives more useful output.
To get around the problem of not knowing what was different for larger objects, we wrote an assertion that uses reflection to compare the fields one by one. That way we can tell at a glance which field is wrong and what the two values are.

[Dirk Schreckmann]

Originally posted by Jeanne Boyarsky:
To get around the problem of not knowing what was different for larger objects, we wrote an assertion that uses reflection to compare the fields one by one. That way we can tell at a glance which field is wrong and what the two values are.

Jeanne,
Have you made that utility publicly available somewhere?

[Lasse Koskela]

Originally posted by Jeanne Boyarsky:
Lasse,
Why would you use
assertTrue(expected.equals(actual))
instead of
assertEquals(expected, actual) ?

Ah. True. Obviously assertEquals() would work better. I did have a point, though, but I can't remember anymore what it was...
[ February 17, 2004: Message edited by: Lasse Koskela ]

[Jeanne Boyarsky]

Jeanne,
Have you made that utility publicly available somewhere?

Dirk,
No, but I can post in this thread tomorrow.

[Jeff Langr]

I've been using a similar utility to compare fields. I cleaned it up a bit and put it here.
-j-

[Jeanne Boyarsky]

These are the methods I was describing:

public void assertEquals(
Object obj1,
Object obj2,
Class targetClass) {
assertEquals(obj1, obj2, targetClass, false);
}
public void assertEqualsIgnoreTime(
Object obj1,
Object obj2,
Class targetClass) {
assertEquals(obj1, obj2, targetClass, true);
}
public void assertEquals(
Object obj1,
Object obj2,
Class targetClass,
boolean ignoreTime) {
Field[] targetAttrDescArray = targetClass.getDeclaredFields();
Field.setAccessible(targetAttrDescArray, true);
Object value1 = null;
Object value2 = null;
for (int i = 0; i < targetAttrDescArray.length; i++) {
try {
value1 = targetAttrDescArray[i].get(obj1);
value2 = targetAttrDescArray[i].get(obj2);
} catch (IllegalAccessException iae) {
fail("IllegalAccessException");
}
if (value1 != null || value2 != null) {
assertNotNull("first value is null and second is not", value1);
assertNotNull("second value is null and first is not", value2);
// Caller should explicitly call checkEqualsCollection on the collection attribute
if ((value1 instanceof java.util.ArrayList)
|| (value1 instanceof java.util.Vector))
continue;
if (ignoreTime == true && value1 instanceof Date) {
assertDatesEqual((Date) value1, (Date) value2);
}
assertEquals("values not equal", value1, value2);
}
}
}

// tests date is correct, regardless of time
public void assertDatesEqual(Date date1, Date date2) {
Calendar cal = Calendar.getInstance();
cal.setTime(date1);

assertDateEquals( date2, cal.get(Calendar.YEAR),
cal.get(Calendar.MONTH),
cal.get(Calendar.DAY_OF_MONTH) );
}
}