Modifying the implementation to make sure the tests fail is exactly what heckle does in ruby. Using it as a mechanism for refactoring is novel tho... I'll have to poke around with that. Thanks!
Often there are several ways of breaking the code to make the test fail. How to you choose the "right way"?
By breaking the code in a single way, you only know that your refactoring of the test code didn't stop testing that single aspect. But it may now let other bugs pass by that where tested before. So do you also - after the refactoring - break the tested code in other ways to make sure you didn't weaken the test code in any other way?
The key insight here is "failure is the test for tests".
ReplyDeleteModifying the implementation to make sure the tests fail is exactly what heckle does in ruby. Using it as a mechanism for refactoring is novel tho... I'll have to poke around with that. Thanks!
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteThis comment has been removed by a blog administrator.
ReplyDeleteOften there are several ways of breaking the code to make the test fail. How to you choose the "right way"?
ReplyDeleteBy breaking the code in a single way, you only know that your refactoring of the test code didn't stop testing that single aspect. But it may now let other bugs pass by that where tested before. So do you also - after the refactoring - break the tested code in other ways to make sure you didn't weaken the test code in any other way?