> But the end result of writing tests is often that you create a lot of testing tied to what should be implementation details of the code.
This is the major issue I have with blind obedience to TDD.
It often feels like the question of "What SHOULD this be doing" isn't asked and instead what you end up with is a test suite that answers the question "What is this currently doing?"
If refactoring code causes you to refactor tests, then your tests are too tightly coupled to implementation.
Perhaps the missing step to TDD is deleting or refactoring the test at the end of the process so you better capture intent rather than the flow of consciousness.
Example: I've seen code that had different code paths to send in a test "logger" to ensure the logger was called at the right locations and said the right messages. That made it difficult add new information to the logger or add new logger messages. And for what?
If your goal is to avoid coupling tests to implementation then TDD seems like the most obvious strategy. You write the test before the implementation, so it is much harder to end up with the coupling than other strategies.
This is the major issue I have with blind obedience to TDD.
It often feels like the question of "What SHOULD this be doing" isn't asked and instead what you end up with is a test suite that answers the question "What is this currently doing?"
If refactoring code causes you to refactor tests, then your tests are too tightly coupled to implementation.
Perhaps the missing step to TDD is deleting or refactoring the test at the end of the process so you better capture intent rather than the flow of consciousness.
Example: I've seen code that had different code paths to send in a test "logger" to ensure the logger was called at the right locations and said the right messages. That made it difficult add new information to the logger or add new logger messages. And for what?