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.
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... :)
Giorgio
September 7, 2009 at 4:32 PM@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.
Unknown
September 7, 2009 at 4:58 PM@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.
Kia Kroas
September 7, 2009 at 10:37 PMGarry@moistdesigns
September 21, 2009 at 8:04 AMThis 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..
Roman
November 22, 2009 at 1:08 AM