Measuring Effective Unit Tests
What is an effective unit test?
A good unit test (via Jeremy Miller) is
- Atomic
- Independent & Isolated
- Intention Revealing
- Easy to Setup
- Runs Fast
But how do we know that the test is effective?
The biggest value of unit tests come when they fail. When a test fails, and we fix it, we have saved considerable time in discovering the bug, pinpointing the failing scenario and fixing it. The more bugs we find early on and the faster we fix them, saves us headaches and time. We also know that the longer we leave a bug in the system, the harder it is to fix.
I have debate this before (Measuring Code Integrity) and I think that measuring the Bug Fix Time is a direct measurement of the effectiveness of our unit tests. I have written a small application that sits on the developers desktop and we are starting to use it in Typemock.
This is what the small application looks like. Each developer can see how long it takes them to fix a test. We still have to tweak the calculation.
We are thinking of counting the failure time only after the first test is run (for TDD teams) although this will not count known bugs, as it is standard to write a test before solving them.
We do consider a group of test that fail together in one run and are solved together in another run as one test.
4 Comments to “Measuring Effective Unit Tests”
Recent Posts
- Unacceptable: Unit testing will take 20 years to catch on
- The 4 reasons why we DIDN’T choose Oslo
- Typemock Academy Launch
- The First Rule to Software Craftsmanship
- Goal-driven Development
Categories
- .NET Tests
- Agile
- Code Integrity
- Community
- Debugging
- Fun
- Management for Geeks
- Marketing
- Product
- Release
- Reviews
- SharePoint
- TDD
- Time Management
- Uncategorized
- Unit Tests
Archives
- May 2010
- April 2010
- March 2010
- February 2010
- December 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- December 2008
- November 2008
- August 2008
- July 2008
- May 2008
- April 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006

[REMOVED]
Great post Brian,
I will send you a copy of the application, although it is very early stage. We are trying to see how this metric helps.
I was once asked about ‘the effort’ for completing test coverage and how much it costs the company writing all the tests, I summarized my response in this blog post and I think it’s relative to what you’ve written here.
http://vsteamsystemcentral.com/cs21/blogs/brian_johnston/archive/2009/04/07/costs-of-unit-testing-vs-not-unit-testing-and-the-last-15-for-code-coverage.aspx
I would *love* get a copy of this program your describing if you were to ever to share it with the rest of the world.
[...] a few weeks using the BugFixTime metric, I found that metric too hard to understand and leaves the developer and managers clueless [...]