• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

do you use message field on assertions?

 
author & internet detective
Posts: 41860
908
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
At Lasse's Server Side breakout session, I noticed he didn't have the String message parameter in any of the examples. When I asked, Lasse said he feels it makes the tests harder to read or doesn't add clarity or something like that.

The following are the first unit tests I've written since that discussion. I'm not clear how the message doesn't help.
If the tests fails, it says "java.lang.AssertionError: #attachments expected: <1> but was: <3>" instead of "java.lang.AssertionError: expected: <1> but was: <3>"
Here's a few reasons:
1) The failure message is more descriptive and tells me the magic numbers 1 and 3 pertain to the number of attachments.
1a) I don't need to click on the failure to see why it is failing
1b) If I have multiple assertions, I know which one is failing
1c) If the nightly build fails, I can see why without having to go to the code by looking up the line number
2) Writing a message string encourages the code author to think about what the assertion is testing.

I'm hoping Lasse or someone else with the same opinion reads this so I can better understand the reasoning. Or just know that it depends on circumstances. In a true TDD environment, I'm guessing some of these don't come up. (or aren't an issue since you wrote the offending code a minute ago)

 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic