Win a copy of Microservices Testing (Live Project) this week in the Spring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

Pragmatic Unit Testing: single assert per test?

 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
author
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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:

Of course this approach hides the actual difference between the two objects...
 
Author
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
author & internet detective
Posts: 41184
848
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
author & internet detective
Posts: 41184
848
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jeanne,
Have you made that utility publicly available somewhere?


Dirk,
No, but I can post in this thread tomorrow.
 
Jeff Langr
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've been using a similar utility to compare fields. I cleaned it up a bit and put it here.
-j-
 
Jeanne Boyarsky
author & internet detective
Posts: 41184
848
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
These are the methods I was describing:
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic