Comments on: Unit tests are production code http://erichauser.net/2009/05/16/unit-tests-are-production-code/ J2EE, .NET, and general technology Fri, 30 Oct 2009 01:03:14 +0000 http://wordpress.org/?v=2.8.5 hourly 1 By: ehauser http://erichauser.net/2009/05/16/unit-tests-are-production-code/comment-page-1/#comment-130 ehauser Wed, 20 May 2009 04:25:51 +0000 http://erichauser.net/2009/05/16/unit-tests-are-production-code/#comment-130 EP - I'm not sure what the reasoning behind it was, I just saw it in a goals document. I am sure the thinking was that we really need to get our tests fixed, which is a good goal. I'm just advocating that there is really one valid state for tests - green. EP – I’m not sure what the reasoning behind it was, I just saw it in a goals document. I am sure the thinking was that we really need to get our tests fixed, which is a good goal. I’m just advocating that there is really one valid state for tests – green.

]]> By: Eric Peters http://erichauser.net/2009/05/16/unit-tests-are-production-code/comment-page-1/#comment-128 Eric Peters Sat, 16 May 2009 16:42:42 +0000 http://erichauser.net/2009/05/16/unit-tests-are-production-code/#comment-128 I couldn't agree more -- Unit tests are production code; and 100% of unit tests should be passing at each commit. However, you left out another key issue: code coverage by the unit tests. I'm working on a large 10 year old software package with a great deal of legacy technical debt. Our build process will fail if the coverage drops at all. So, even though we're still only marginally above 50% coverage (due to legacy code), no new code gets into the code base without 100% coverage. It's quite effective, especially with a fully automated build/test processes triggered by each svn commit. Was there justification for the 80% line of thinking? That stance sounds equivalent to saying that 20% broken is okay. I couldn’t agree more — Unit tests are production code; and 100% of unit tests should be passing at each commit. However, you left out another key issue: code coverage by the unit tests.

I’m working on a large 10 year old software package with a great deal of legacy technical debt. Our build process will fail if the coverage drops at all. So, even though we’re still only marginally above 50% coverage (due to legacy code), no new code gets into the code base without 100% coverage. It’s quite effective, especially with a fully automated build/test processes triggered by each svn commit.

Was there justification for the 80% line of thinking? That stance sounds equivalent to saying that 20% broken is okay.

]]>