You are describing the correct way to do things, design what you're going to do before writing any code or tests... but that isn't TDD. If you're writing any code before writing tests for that code, then you aren't doing TDD and that's fine, because really no one should be doing TDD. Both tests and code should be driven by the design, and that's the problem with TDD, they think that test implementation driving design is somehow better than code implementation driving design, when both are bad.
So, you're on the right track, but instead of trying to redefine away the only defining feature of TDD, just drop the silly practice entirely. Write good designs and make sure that both tests and code conform to those designs.
I believe I haven't redefine TDD. When TDD says that you need to write tests before code, it means production code, not any type of code.
At least that is my interpretation. I don't think it make sense to interprete test before code as test before any type of code. That means you cannot even fire an REPL or write Linux script since it is also some form of code. We can even say TDD forbid the usage of git pull in the bash since it is some type of code.
I think the literal interpretation is both unrealistic and unfair to the practice.
That's why I believe TDD mean test before production code, not any type of code. And my article align with this interpretation.
And again, we can argue wether TDD is something useful or should be ditched. But that is another story. I can say that it have its own upside and downside.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You are describing the correct way to do things, design what you're going to do before writing any code or tests... but that isn't TDD. If you're writing any code before writing tests for that code, then you aren't doing TDD and that's fine, because really no one should be doing TDD. Both tests and code should be driven by the design, and that's the problem with TDD, they think that test implementation driving design is somehow better than code implementation driving design, when both are bad.
So, you're on the right track, but instead of trying to redefine away the only defining feature of TDD, just drop the silly practice entirely. Write good designs and make sure that both tests and code conform to those designs.
I believe I haven't redefine TDD. When TDD says that you need to write tests before code, it means production code, not any type of code.
At least that is my interpretation. I don't think it make sense to interprete test before code as test before any type of code. That means you cannot even fire an REPL or write Linux script since it is also some form of code. We can even say TDD forbid the usage of
git pullin the bash since it is some type of code.I think the literal interpretation is both unrealistic and unfair to the practice.
That's why I believe TDD mean test before production code, not any type of code. And my article align with this interpretation.
And again, we can argue wether TDD is something useful or should be ditched. But that is another story. I can say that it have its own upside and downside.