Comments on: On the topic of assertions http://www.hackerdude.com/2007/03/06/on-the-topic-of-assertions/ Software Development Blog Sat, 05 Jul 2008 01:26:27 +0000 http://wordpress.org/?v=2.5.1 By: Hackerdude http://www.hackerdude.com/2007/03/06/on-the-topic-of-assertions/#comment-5369 Hackerdude Mon, 12 Mar 2007 23:07:35 +0000 http://www.hackerdude.com/2007/03/06/on-the-topic-of-assertions/#comment-5369 Well, that's probably an exception. If your test name creates a redunancy you probably don't need to add it twice out of respect of the DRY principle. However under some circumstances (integration tests come to mind, and there may be others) you need more than one assertion per test so the build time doesn't become a problem (long build times can kill a project, so some project managers tell me). At other times I worry about the granularity of the tests becoming a barrier to non-developers who want to know the status of the project. I fear that so many individual tests (as opposed to multiple assertions inside an overarching test) may add to confusion if your audience (the people who read the junit results) is composed of more than developers. It brings to bear the debate of <a href="http://www.elilopian.com/2006/10/31/multiple-asserts-in-a-single-unit-test/" rel="nofollow">one assertion per test vs. one assertion per scenario</a>. No silver bullet of course. So although Rob's point is indeed an important clarification, still keep in mind that if you have to have more than one assertion, do make sure you add strings to them. Also make sure those methods really are descriptive. Well, that’s probably an exception. If your test name creates a redunancy you probably don’t need to add it twice out of respect of the DRY principle. However under some circumstances (integration tests come to mind, and there may be others) you need more than one assertion per test so the build time doesn’t become a problem (long build times can kill a project, so some project managers tell me).

At other times I worry about the granularity of the tests becoming a barrier to non-developers who want to know the status of the project. I fear that so many individual tests (as opposed to multiple assertions inside an overarching test) may add to confusion if your audience (the people who read the junit results) is composed of more than developers. It brings to bear the debate of one assertion per test vs. one assertion per scenario. No silver bullet of course.

So although Rob’s point is indeed an important clarification, still keep in mind that if you have to have more than one assertion, do make sure you add strings to them. Also make sure those methods really are descriptive.

]]> By: Rob Meyer http://www.hackerdude.com/2007/03/06/on-the-topic-of-assertions/#comment-5072 Rob Meyer Wed, 07 Mar 2007 00:29:46 +0000 http://www.hackerdude.com/2007/03/06/on-the-topic-of-assertions/#comment-5072 I've never quite been able to reconcile their redundancy with the test names. I'm okay with assertion descriptions, but I do think that if your tests are well named and match the assertion (and there's just one), it still remains pretty clear. ex: public void Test_ViewIsPopulatedWithMySuperDuperFlag_When_UserIsSuperDuper() { // blah blah assertTrue(view.SuperDuperFlag); } I think the report from a test like that is totally readable. I like having very descriptive test names, and if you have them the descriptions sometimes seem redundant. Now, if you have one of those cases where the assertion is not so obvious, or you're (for a decent reason) doing multiple assertions, descriptions are perfect. I’ve never quite been able to reconcile their redundancy with the test names.

I’m okay with assertion descriptions, but I do think that if your tests are well named and match the assertion (and there’s just one), it still remains pretty clear. ex:

public void Test_ViewIsPopulatedWithMySuperDuperFlag_When_UserIsSuperDuper()
{
// blah blah
assertTrue(view.SuperDuperFlag);
}

I think the report from a test like that is totally readable. I like having very descriptive test names, and if you have them the descriptions sometimes seem redundant.

Now, if you have one of those cases where the assertion is not so obvious, or you’re (for a decent reason) doing multiple assertions, descriptions are perfect.

]]>