How do you achieve 100% test coverage?

When doing Test-Driven Development, one critical metric is test coverage. And it is often quite difficult to achieve 100% test coverage on a given method using its "normal" unit tests.

This can often lead to very strange looking test code written specifically to test all possible branches and every corner case. Sometimes this is useful, but more often than not its testing for testings sake.

But if your test suite is good enough and tests all the designed behavior, uncovered code is a good indication of unused code. Try to delete it. If it still compiles and all tests pass, the code was dead weight code you can safely remove.

This is specifically often true for getters and setters for each and every attribute on a particular class. Put YAGNI (You Ain't Gonna Need It) to use and remove all setters and getters not in active use by your code. If you need one later, you could always add it. This makes the code much more compact and easier to read.

But what if the getters and setters are part of an API? Well, then the API should be an interface, shouldn't it?

When is a feature done?

Far too often a new feature is considered done at an incomplete state.

This is my suggested checklist for when to consider a feature DONE:

1. It's checked in to source control
2. It compiles
3. It passes its unit tests (no, not having unit tests does not count)
4. It doesn't break any other unit tests
5. It increases the overall test coverage for the module
6. The continuous integration server passes the build
7. It's integration tested with other features and / or modules it pertains to
8. It's documented in the release notes and / or product documentation
9. The feature does what it's supposed to do (as defined by the specifications for the feature)
   

If you answer no to any of these questions, you're not done. Furthermore, if you answer N/A to any of them you should ask yourself whether the feature should be implemented at all.

The last point is perhaps the most difficult to assess, unless you have executable specifications in form of FIT tests or something similar. Furthermore, if you're using Scrum, the feature must be demonstrated on the end-of-iteration demo to be considered done.