Most (all?) TDD resources show you how the cycle goes:
- Write Test
- Check Test
- Write Production Code
- Check Test
- Clean up Production Code
- Check test
They also - to me - seem to imply that all code is covered by tests.
However, reading posts like Writing Great Unit Tests: Best and Worst Practices (for example, linked to here) it's said that
TDD is a robust way of designing software components (“units”) interactively so that their behaviour is specified through unit tests
To fill in some more context:
At the other end of the scale, integration tests contain no knowledge about how your codebase is broken down into units, but instead make statements about how the whole system behaves towards an external user.
This makes perfect sense to me. However, it implies that large parts of the applications code are not covered by tests. Why? Because if you have units (and you need a lot of units to get your Unit Tests right) you need code that wires the units together. This code, IMHO, will get complicated enough that it deserves to be tested on a more granular level that integration tests while it probably falls into "Dirty Hybris":
Anywhere in between, it’s unclear what assumptions you’re making and what you’re trying to prove. Refactoring might break these tests, or it might not, regardless of whether the end-user experience still works
So to sum up:
- I easily see the value of Unit Tests with TDD
- Some code is needed to wire the units together
- This code will be complex and integration testing will/may not be enough.
- TDD resources on the net seem to imply 100% code/test coverage, yet
- looking at TDD with True Unit Tests will leave some code untested
Edit: wikipedia says:
Integration testing takes as its input modules that have been unit tested
but somehow I feel there's still quite a bit of wiring code missing from the picture. (except if "module" means "class or function" because that is what's unit tested in isolation)