My #1 Testing Pattern

Sex... to save the friendship - Jerry Seinfeld (The Mango)

This pattern is not the one that I most frequently use. Far from it. It is just the one the I like the most because it delivers a sense of reassurance and peace.

So, sometimes you lose your confidence. You no longer believe that your test suite is doing its work. Lost faith threatens to bring down the whole development cycle: you cannot refactor/change/add because a Green bar will no longer indicate "no bugs".

This problem often happens after a long refactoring session. When you're finally done you run the tests expecting a Red - you're sure you broke something. To your surprise you get Green. You now have doubts. Is the Green really Green?

Whatever the reason for this distrust is, this is a very dangerous situation.

Luckily, there is a simple solution: Start breaking your code.

Pick a random point in your code and change it. Return null from a method. Throw an exception. Comment out an assignment to a field. Whatever. Just break the code. Now run the tests again. If your tests are OK you will get a Red bar. This will raise your confidence level: the test suite just showed you that things are under control. You should now undo this bug that you just introduced and repeat this process with a different program-breaking change. The more you repeat it, the more confidence you will gain.

On the other hand, if you get Green after breaking the code, then your distrust is justified. You do have a problem. You should write more tests, starting - wait for it - right now.

5 comments :: My #1 Testing Pattern

  1. This is more a practice than a pattern, but it is true. In an ideal world, though, test code will be always written before production code to make sure it fails... :)

  2. @Giorgio
    "test code will be always written before production code to make sure it fails" - true, but in cases such as refactoring you do not write tests before you do the refactoring.

  3. @Giorgio

    Yup. It's a pattern, Test Driven Development.

    @Itay Maman

    When you refactor, the tests should all be the same...unless you're changing functionality.

  4. This comment has been removed by a blog administrator.
  5. This is a great suggestion. I find myself doing essentially the same whenever I need to write tests AFTER i've actually written the code.

    This is also a good way to check how effective your QA actually is: create 100 random bugs in your code - if x bugs are found, you can assume that around x% of the unintended bugs are found as well..

Post a Comment