Testing Your Unit Tests

Someone in the Ruby community thought it was a good idea to write a piece of software that tested your unit tests.

Heckle runs your standard Ruby unit tests and reports as per normal. Heckle then alters a certain amount of your Ruby source code and then re-executes your unit tests, reporting on the subsequent run against the altered source code. If your unit tests don’t fail after Heckle has mutated your initial source code, then it proves that certain sections of your application either aren’t covered by tests at all or that they aren’t thorough enough.

I don’t know how many people would use a unit testing utility like Heckle, however anything that can be used to increase the robustness of your code is a good thing I think.

2 thoughts on “Testing Your Unit Tests

  1. It’s a nice idea, but it sounds like a very inaccurate version of code coverage from the description. What guarantee is there that changing some code (assuming it even compiles) could fail a test? Your code might be that robust that it actually handles the change :) I’d expect it to yield a number of false-positives. Assuming code coverage is available, what benefit does this provide?

  2. Paul,

    I was going to edit the post earlier to clarify that exact point.

    Using a utility like Heckle for Ruby, or Jester for Java; isn’t a substitute for code coverage. In fact, Ruby has code coverage facilities within it.

    What Heckle does do though, is alter certain portions of your code in a predictable manner. Kevin Clark has some code snippets and a little deeper explanation on tormenting your tests with Heckle if you’re interested.


Comments are closed.