this post was submitted on 05 Aug 2023
644 points (97.8% liked)
Programmer Humor
32410 readers
1 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 6 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
TDD is great when you have a very narrow use case, for example an algorithm. Where you already know beforehand: If I throw A in B should come out. If I throw B in C should come out. If I throw Z in an error should be thrown. And so on.
For that it's awesome, which is mostly algorithms.
In real CRUD apps though? You have to write the actual implementation before the tests. Because in the tests you have to mock all the dependencies you used. Come up with fake test data. Mock functions from other classes you aren't currently testing and so on. You could try TDD for this, but then you probably spend ten times longer writing and re-writing tests :-/
After a while it boils down to: Small unit tests where they make sense. Then system wide integration tests for complex use-cases.
It's also great for bug fixes. Write that sucker first and you have an easy way to reproduce the issue and check whether it's fixed.
Yeah, I'm constantly recommending junior devs to use TDD specifically for this. I don't recommend it for anything else. If they don't write the test first, it's possible that the test will end up testing the wrong thing and thus they can't be sure they really did fix the bug.
Sometimes it's hard to tell where to write the test ahead of time, so sometimes a slight variation I do is to write the test after (usually because it was such a struggle to figure out where the bug is), but when I'm testing it, I'll comment out the fix or whatever and make sure the test fails.