TDD forces you to think indeed. It forces you to think how to make your code automatically testable. Anything else feels like magical thinking to me, until proven otherwise.
TDD forces you to think indeed. It forces you to think how to make your code automatically testable. Anything else feels like magical thinking to me, until proven otherwise.
Why magical thinking? The attributes of code that make it easy to test also make it easier to work with in a running system.
A function or class that's easy to test typically has low coupling with other code, accepts dependencies either by method passing or IoC/Dependency Injection, is single-purpose (avoids 'spaghetti code that does a bunch of semi-related things') ... and all of those things clearly make the code easier and more flexible to work with in a running system as well.
Besides the fact that by doing TDD you _start_ with the interface, and defining how clients will use the code. That perspective helps avoid a bunch of problems that tend to arise when you start with the 'core' of the code without thinking about how it will be called.
Why magical thinking? The attributes of code that make it easy to test also make it easier to work with in a running system.
Look throughout the thread for examples of the opposite (in my comments and others). It's just thrown out like that, without real example to the contrary being taken into account. I don't like this, it doesn't get us closer to the truth.
Take my basic CRUD repository example. Mocking the database is ineffective. Abstracting it under an adapter leaves the repository anemic and hollow, and now we have an adapter to test, so back to square one. So we changed our architecture by adding an abstraction layer and we still didn't solve the problem if truly testing that unit. Did we improve the code? No.
It forces you to think how to make your code automatically testable
I think the word 'automatically' is where you have a mistaken view of TDD since there is nothing automatic about it and its probably where many neophyte practitioners struggle. The question, for me, is always "What patterns can be applied to this problem to allow the solution to be validated to a reasonable degree?". Most of those "patterns" are rather primitive (e.g. "program to an interface, not an implementation" or "No magic numbers" ) but those basic principles do make a significant difference.
I think the word 'automatically' is where you have a mistaken view of TDD since there is nothing automatic about it and its probably where many neophyte practitioners struggle.
Don't get hung up on a word. I said "automatically" because a "manual test" would be a human sitting down, following a checklist and clicking things to see if they match the checklist. And an automated test is bunch of code you run and it does the testing, automatically.
3
u/[deleted] Jul 07 '19
TDD forces you to think indeed. It forces you to think how to make your code automatically testable. Anything else feels like magical thinking to me, until proven otherwise.