Comments on: TDD: Tests that give us a false confidence of coverage http://www.markhneedham.com/blog/2009/09/21/tdd-tests-that-give-us-a-false-confidence-of-coverage/ Thoughts on Software Development Tue, 16 Mar 2010 16:49:52 +0000 http://wordpress.org/?v=2.8.4 hourly 1 By: Alexandre Gazola http://www.markhneedham.com/blog/2009/09/21/tdd-tests-that-give-us-a-false-confidence-of-coverage/comment-page-1/#comment-24121 Alexandre Gazola Mon, 12 Oct 2009 22:22:53 +0000 http://www.markhneedham.com/blog/?p=1663#comment-24121 Great point, Mark! That's really something to watch out for. Having false testing coverage can be worse than having no tests at all. Great point, Mark! That's really something to watch out for. Having false testing coverage can be worse than having no tests at all.

]]> By: Michael Stum http://www.markhneedham.com/blog/2009/09/21/tdd-tests-that-give-us-a-false-confidence-of-coverage/comment-page-1/#comment-22883 Michael Stum Tue, 22 Sep 2009 17:56:11 +0000 http://www.markhneedham.com/blog/?p=1663#comment-22883 Fully agree with point 1. One problem seems to be that there are conflicting "rules" and some people are not sure which one to follow. There is a "rule" that says "Only one assert per test, as you don't know which one failed". That would mean "One Test per Property", and as tests are usually created through copy/paste, you end up with 15 tests that all do the same except for one assert. At some point that then creates such a big overhead (every intentional change breaks 15 tests at once that all need to be fixed) that people move away from TDD and think it's clumsy. Another "rule" is that simple Getters/Setters do not need to be tested because it is expected that they run. However, this "rule" specifically applies to simple POCOs, not to business classes. Finding the right balance can only be achieved through experience, but I think that many people never move beyond the Assert.IsTrue(1+1,2) level, because Unit Testing becomes a lot more complicated afterwards. Fully agree with point 1. One problem seems to be that there are conflicting "rules" and some people are not sure which one to follow. There is a "rule" that says "Only one assert per test, as you don't know which one failed". That would mean "One Test per Property", and as tests are usually created through copy/paste, you end up with 15 tests that all do the same except for one assert. At some point that then creates such a big overhead (every intentional change breaks 15 tests at once that all need to be fixed) that people move away from TDD and think it's clumsy. Another "rule" is that simple Getters/Setters do not need to be tested because it is expected that they run. However, this "rule" specifically applies to simple POCOs, not to business classes.

Finding the right balance can only be achieved through experience, but I think that many people never move beyond the Assert.IsTrue(1+1,2) level, because Unit Testing becomes a lot more complicated afterwards.

]]> By: Reflective Perspective - Chris Alcock » The Morning Brew #438 http://www.markhneedham.com/blog/2009/09/21/tdd-tests-that-give-us-a-false-confidence-of-coverage/comment-page-1/#comment-22862 Reflective Perspective - Chris Alcock » The Morning Brew #438 Tue, 22 Sep 2009 07:18:17 +0000 http://www.markhneedham.com/blog/?p=1663#comment-22862 [...] TDD: Tests that give us a false confidence of coverage - Mark Needham talks about some classes of test which do nothing to improve the confidence in the application due to the way the tests exercise the code but don’t actually check anything important is correct [...] [...] TDD: Tests that give us a false confidence of coverage – Mark Needham talks about some classes of test which do nothing to improve the confidence in the application due to the way the tests exercise the code but don't actually check anything important is correct [...]

]]>