this post was submitted on 02 Nov 2023
1396 points (98.5% liked)
Programmer Humor
32571 readers
131 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
TDD doesn't imply that you write all the tests first. It just mean you have to write a test before you write a line of production code.
The idea is to ask yourself "what is the first step I need, where am I going to begin?". You then write a test that validate this first step and fail. Then you write the code to make it pass. Once your done with that, you ask yourself: "what's the next step? ". You, then, repeat the process for that step.
This is a process you are going to do anyway. Might as well take the time to write some test along with it.
That leads to focusing on the nitty gritty details first, building a library of thing you think you might need and you forget to think about the whole solution.
If you come up with another solution half way through, you will probably throw away half of the code you already built.
I see TDD as going depth first whereas I prefer to go breadth first. Try out a solution and skip the details (by mocking or assuming things). Once you have settled on the right solution you can fill in the details.