dcsimg
Best practices for messages in asserts
2 posts in topic
Flat View  Flat View
TOPIC ACTIONS:
 

Posted By:   brian_surratt
Posted On:   Friday, April 5, 2002 10:49 AM

Is there a consensus on the best way to phrase the messages used in JUnit asserts? I'm inclined to make the message describe the failure condition. For example: assertNotNull("the object was null", theObject); assertEquals("the number did not equal 3", 3, theNumber); This would make the failure more meaningful when it is displayed. However, the concept of an assertion is that you're saying "Hey, this should be true". This suggests that following might be more correct: assertNotNull("the object was not null", theObject); assertEquals("the number equals 3", 3, theNumber);    More>>


Is there a consensus on the best way to phrase the messages used in JUnit asserts? I'm inclined to make the message describe the failure condition. For example:



			
assertNotNull("the object was null", theObject);
assertEquals("the number did not equal 3", 3, theNumber);


This would make the failure more meaningful when it is displayed.


However, the concept of an assertion is that you're saying "Hey, this should be true". This suggests that following might be more correct:



			
assertNotNull("the object was not null", theObject);
assertEquals("the number equals 3", 3, theNumber);



I browsed the JUnit home page and could not find anything to provide guidance.



Thanks,

Brian

   <<Less

Re: Best practices for messages in asserts

Posted By:   Thomas_SMETS  
Posted On:   Tuesday, April 16, 2002 04:31 PM

There is also a hidden timing thing beyond that !

If you present the failling code & have it evaluated you end up having the evey asserted statement being evaluated twice, like in :


assertEquals ("Identity operation does not evaluate to true. Returned : " + evaluateIdentity(someValue)
+ "Expected : " + someValue,
evaluateIdentity(someValue),
someValue );


This code implies that the evaluateIdentity(someValue) is invoked twice. Now if you have tha method showing an Object with a meaningfull toString () method, you end up having the toString () method called twice...


Every improvement in the fedd back may each time cost twice what it is !



Thomas SMETS,

SCJP, Brussels

Re: Best practices for messages in asserts

Posted By:   Anonymous  
Posted On:   Tuesday, April 9, 2002 10:29 AM

Generally, I try to make my test methods small enough that I don't find it necessary to use the optional message parameter.

If I feel a message would help, I use your second suggestion, letting it state the expected state. I don't know of any widely spread convention, though.

About | Sitemap | Contact