Comments on: Striving for 100 percent http://millarian.com/programming/striving-for-100-percent/ Musings of a startup junkie and Ruby on Rails nerd. Mon, 21 Jun 2010 10:11:51 +0000 hourly 1 http://wordpress.org/?v=3.0 By: heidmotron http://millarian.com/programming/striving-for-100-percent/comment-page-1/#comment-20 heidmotron Wed, 30 Nov -0001 00:00:00 +0000 <p>I would say the goal of testing is not to get a 100% badge. But at the same I would say if a function is easy to write, it should be easy to test. If it isn’t, was the function created really that easy. Were all the nuances taken into account? Could you be confident that it would work 100% of the time? And maybe a question to the customer would be what level of uncertainty do they risk by not having a good test suite? It’s something that I think over time it’s easier to see the value than right off the bat.</p> I would say the goal of testing is not to get a 100% badge. But at the same I would say if a function is easy to write, it should be easy to test. If it isn’t, was the function created really that easy. Were all the nuances taken into account? Could you be confident that it would work 100% of the time? And maybe a question to the customer would be what level of uncertainty do they risk by not having a good test suite? It’s something that I think over time it’s easier to see the value than right off the bat.

]]> By: Curtis http://millarian.com/programming/striving-for-100-percent/comment-page-1/#comment-21 Curtis Wed, 30 Nov -0001 00:00:00 +0000 <p>@heidmotron, thanks for the comment.</p> <p>I agree that functions <em>should</em> be easy to test, but certain aspects of testing can be pretty tricky. This is especially true when dealing with negative path cases.</p> <p>I also don’t necessarily equate 100% coverage with 100% tested, although that occurs sometimes. <acronym title="In My Opinion">IMO</acronym>, coverage should not really be used as the sole measure of quality. Coverage merely lets you know that a line of code was executed during a test. You’re not assured that line of code was executed with all permutations and therefore cannot be sure it works for any cases other than those tested, despite the results of your code coverage utility.</p> <p>Support for mocks and stubs in <a href="http://rspec.rubyforge.org">Rspec</a> is certainly making it easier to get good coverage, but there are still some tricky cases that take more time to get coverage for. Perhaps as I become more versed and seasoned with Rspec I will overcome those challenges more easily.</p> @heidmotron, thanks for the comment.

I agree that functions should be easy to test, but certain aspects of testing can be pretty tricky. This is especially true when dealing with negative path cases.

I also don’t necessarily equate 100% coverage with 100% tested, although that occurs sometimes. IMO, coverage should not really be used as the sole measure of quality. Coverage merely lets you know that a line of code was executed during a test. You’re not assured that line of code was executed with all permutations and therefore cannot be sure it works for any cases other than those tested, despite the results of your code coverage utility.

Support for mocks and stubs in Rspec is certainly making it easier to get good coverage, but there are still some tricky cases that take more time to get coverage for. Perhaps as I become more versed and seasoned with Rspec I will overcome those challenges more easily.

]]>