Comments on: Unit Test Assertions: What Could Possibly Go Wrong?

By: Pramatr

Pramatr — Fri, 21 Nov 2008 18:56:00 +0000

@Asgeir S. Nilsen: Thanks for the tip, I have looked at this briefly but I haven’t really played with it enough to have an opinion . I does look handy though, I’m interested to see how useful it is.

By: Asgeir S. Nilsen

Asgeir S. Nilsen — Wed, 14 Nov 2007 10:43:00 +0000

Nice article. One suggestion to get more readable messages is to use JUnit 4.4's assertThat method together with hamcrest matchers.

You can then state an assertion as

assertThat(actual, equalTo(expected));

and get a very nice error message back if the assertion fails.

By: Pramatr

Pramatr — Mon, 12 Nov 2007 19:25:00 +0000

The message versions are very much personal preference. The book I mentioned does discuss this issue a little. If you are running this through Eclipse and following TDD, I can completely understand your point. One assertion per test, why do I need a message? Lots of the tests I’ve had to maintain however, haven’t been this well written. The message therefore helps example the maintainer understand what’s going on.

I do prefer your chosen TDD approach , it’s pretty hard convincing everyone it’s the way to go however.

By: Dean

Dean — Mon, 12 Nov 2007 19:03:00 +0000

I rarely use the message versions of the assertions. I use very meaningful names everywhere, I run all my tests in Eclipse where I get a clickable stack trace, I use TDD so I know what I just changed since the last test run, and I use the expected vs. actual assertions where possible. As a result, I rarely need more information. Not writing the messages reduces clutter, saves a lot of time, and requires zero maintenance of the messages!

By: Adam Peters

Adam Peters — Sun, 11 Nov 2007 16:53:00 +0000

xUnit Test Patterns sounds like an interesting read. Thanks for the links to the site, I’d be quite interested to see your review!