Menu
I have been trying to stick to the TDD approach. So I have made some tests and they all fail. Now I am implementing. But now that I am implementing I have seen that the methods are too simple to fail. In particular I have implemented the observer pattern and all that happens is that I notify all the registered observers. So use a for each loop and call notify. This certainly sounds too simple to break. Now that I have the tests in places should I delete them? This also seems to be a bit of a waste of time. So should I try and anticipate methods that would be too simple to break?
360
As a rule, a passing test should never be removed. That's because passing tests serve as the regression tests for our maintenance work. They are there to make sure that when we change code we don t break anything else that s already working.
Robert C. Martin (“Uncle Bob”) provides a concise set of rules for practicing TDD. Write production code only to pass a failing unit test. Write no more of a unit test than sufficient to fail (compilation failures are failures). Write no more production code than necessary to pass the one failing unit test.
In TDD, developers start creating small test cases for every feature based on their initial understanding. The primary intention of this technique is to modify or write new code only if the tests fail. This prevents duplication of test scripts.
No.
The methods may be too simple to break right now, but that doesn't mean they'll never need to be modified (and possibly broken) in the future.
93
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
