I’m about to start looking into developing with the aid of code coverage, and I’m wondering how it typically fits in with test driven development.
Is code coverage an afterthought? Does your process go something like
- Write a test for the functionality to be implemented
- Run test, make sure they fail
- Implement functionality
- Run test, make sure they pass
- Write more tests for the functionality until 100% (or near) code coverage is obtained
Or do you run code coverage at the very end after numerous functional pieces have been implemented and then go back and work towards 100% coverage?
The third option I can think of is strive towards 100% coverage before even implementing the functionality.
Which of these is most common, and what are the benefits?
You don’t write tests until 100% code coverage is achieved. If you’ve been following TDD, then there is no code that was ever written without being required by a test, so you should always be near 100% coverage.
Instead, you write tests until all tests pass, and until all the tests required have been written. This will imply that all the required code has been written, since you will only have written code if it was required by a test.