Comments on: One behavior != one assertion http://blog.agilephp.com/2009/02/21/one-behavior-one-assertion/ Dagfinn Reiersøl on PHP, agile development, Ruby and other addictive substances Thu, 19 Jan 2012 18:39:47 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Buzz Lightyear is here » Blog Archive » links for 2011-06-06 http://blog.agilephp.com/2009/02/21/one-behavior-one-assertion/comment-page-1/#comment-844 Buzz Lightyear is here » Blog Archive » links for 2011-06-06 Mon, 06 Jun 2011 23:03:34 +0000 http://blog.agilephp.com/?p=1483#comment-844 [...] One behavior != one assertion – PHP in Action (tags: php testing tdd phpunit unittesting bdd) [...] [...] One behavior != one assertion – PHP in Action (tags: php testing tdd phpunit unittesting bdd) [...]

]]> By: Thomas http://blog.agilephp.com/2009/02/21/one-behavior-one-assertion/comment-page-1/#comment-207 Thomas Sun, 22 Feb 2009 11:58:06 +0000 http://blog.agilephp.com/?p=1483#comment-207 Oh and I forgot to ask, which codequote-plugin do you use? Oh and I forgot to ask, which codequote-plugin do you use?

]]> By: Thomas http://blog.agilephp.com/2009/02/21/one-behavior-one-assertion/comment-page-1/#comment-206 Thomas Sun, 22 Feb 2009 11:56:24 +0000 http://blog.agilephp.com/?p=1483#comment-206 I agree! This kind of purism for purisms' sake is just wasted time IMHO. I know not a whole lot agree here, but it is the same as with the whole CSS/table thing. Yes, okay, CSS *should* be used for layout (and of course that is my starting point), but sometimes it is just so much easier, quicker and consistent across browsers to just plug a table somewhere and be done with it. It may be an interesting exercise trying to get it just right in CSS, but frankly I like spending my time elsewhere and I'm sure my clients agree.. Are you sure that is what he meant though? Comparing example #1 to #2 and calling #2 superior seems more than a little bit strange.. I agree! This kind of purism for purisms’ sake is just wasted time IMHO. I know not a whole lot agree here, but it is the same as with the whole CSS/table thing. Yes, okay, CSS *should* be used for layout (and of course that is my starting point), but sometimes it is just so much easier, quicker and consistent across browsers to just plug a table somewhere and be done with it. It may be an interesting exercise trying to get it just right in CSS, but frankly I like spending my time elsewhere and I’m sure my clients agree..

Are you sure that is what he meant though? Comparing example #1 to #2 and calling #2 superior seems more than a little bit strange..

]]> By: Padraic Brady http://blog.agilephp.com/2009/02/21/one-behavior-one-assertion/comment-page-1/#comment-205 Padraic Brady Sun, 22 Feb 2009 11:50:03 +0000 http://blog.agilephp.com/?p=1483#comment-205 Admittedly 1 Assertion == 1 Behaviour missed the whole test ;). That wasn't intentional though. I think that we don't disagree to such a huge degree though - I made the point early on in the post: "Now let me disclaim a little - I'm really really sure there are times multiple assertions are needed. So my main point is not that this is an absolute rule with no possible exceptions so help me God, rather that it should be a rule unless you are literally forced to tackle an exception to it." You can read this as you suggested - it's a guideline with exceptions. My goal however is to make sure the exception is actually an exception, and not just an easy way out. Your example can also be mangled a little differently. I agree (without reservation) that the example makes an excellent point but it also proves one of mine. If the product make ends up not being Logitech, there is no way for the test reporter to also tell us if the product model was also incorrect (or correct) since it's completely skipped over once the first assertion fails. This suggests the double assertion might be more informative (bearing in minds tests are documentation and should be as complete and as informative as possible) using a single assertion: $this->assertEquals( array('Logitech', 'Harmony One'), array($product->make, $product->model) ); It might look longer (and it's cheating in one sense ;)), but it is one single assertion and PHPUnit will do something wonderful when it fails - it will print a diff of the two arrays to show where they differed. Now you will definitely see what happens when both Model properties, or only one, fail in contrast to your assertion twins. Admittedly 1 Assertion == 1 Behaviour missed the whole test ;) . That wasn’t intentional though.

I think that we don’t disagree to such a huge degree though – I made the point early on in the post: “Now let me disclaim a little – I’m really really sure there are times multiple assertions are needed. So my main point is not that this is an absolute rule with no possible exceptions so help me God, rather that it should be a rule unless you are literally forced to tackle an exception to it.” You can read this as you suggested – it’s a guideline with exceptions. My goal however is to make sure the exception is actually an exception, and not just an easy way out.

Your example can also be mangled a little differently. I agree (without reservation) that the example makes an excellent point but it also proves one of mine. If the product make ends up not being Logitech, there is no way for the test reporter to also tell us if the product model was also incorrect (or correct) since it’s completely skipped over once the first assertion fails. This suggests the double assertion might be more informative (bearing in minds tests are documentation and should be as complete and as informative as possible) using a single assertion:

$this->assertEquals(
array(‘Logitech’, ‘Harmony One’),
array($product->make, $product->model)
);

It might look longer (and it’s cheating in one sense ;) ), but it is one single assertion and PHPUnit will do something wonderful when it fails – it will print a diff of the two arrays to show where they differed. Now you will definitely see what happens when both Model properties, or only one, fail in contrast to your assertion twins.

]]>