3 ms·

And I think most people who don't write tests in code work that way anyway, just manually -- they F5 the page, or run the code some other way. But the end resu

And I think most people who don't write tests in code work that way anyway, just manually -- they F5 the page, or run the code some other way. 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. E.g. to write "more testable" code, some people advocate making very small functions. But the public API doesn't change. So if you test only the internal functions, you're just making it harder to refractor.

cogman10 4y ago
> 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?
- viceroyalbean 4y ago
  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.
sanderjd 4y ago
I often TDD little chunks of code, end up deciding they make more sense inside larger methods, and delete the tests. But that's ok, the test was still useful to help me develop the chunk of code.

cogman10 4y ago

> 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?

viceroyalbean 4y ago
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.

sanderjd 4y ago

I often TDD little chunks of code, end up deciding they make more sense inside larger methods, and delete the tests. But that's ok, the test was still useful to help me develop the chunk of code.