5 ms·

TDD can be great if you know exactly what you're building and what you must test for But you should know this from your functional requirements, right? (Sligh

TDD can be great if you know exactly what you're building and what you must test for But you should know this from your functional requirements, right? (Slightly sarcastic comment, I know in a lot of places people just start coding without a plan, but I think TDD and functional requirements go together well).

devoutsalsa 4y ago
TDD is pretty useless when the requirements are shit. It just takes longer to realize you need better directions.
- scott_w 4y ago
  Or it tells you straight away that you have no idea what you’re supposed to be doing instead of spending 3 days building the wrong thing.
chrisandchris 4y ago
> ... start coding without a plan ... Well, I don't do that. But i usually don't know all the names of my (internal) interfaces and models and properties right at the start. I might move things around and rename stuff along the way. And I think that's quite normal if you don't live in a world where the spec for a small task is multiple books thick. Doesn't TDD get in the way with? Wouldn't I keep refactoring the tests all the time then?
- missingdays 4y ago
  When you rename an interface or a method, IDE renames them in tests too
dmitriid 4y ago
> But you should know this from your functional requirements, right? Functional requirements describe observable behaviour. You can't write any meaningful tests for that behaviour until a lot of your code is written. Yet somehow in all the discussions there's this unexplaned leap from "you have the requirements" -> "well you just write a unit test for your function first, and then code it". My functional requirements come in the form of "Given publisher A in Country B and contract requirements C the service must return D for a subset of products E", for multiple combinations of A, B, C, D, and E. And where each of those may and will require lookups in external services and databases.

devoutsalsa 4y ago

TDD is pretty useless when the requirements are shit. It just takes longer to realize you need better directions.

scott_w 4y ago
Or it tells you straight away that you have no idea what you’re supposed to be doing instead of spending 3 days building the wrong thing.

chrisandchris 4y ago

> ... start coding without a plan ... Well, I don't do that. But i usually don't know all the names of my (internal) interfaces and models and properties right at the start. I might move things around and rename stuff along the way. And I think that's quite normal if you don't live in a world where the spec for a small task is multiple books thick. Doesn't TDD get in the way with? Wouldn't I keep refactoring the tests all the time then?

missingdays 4y ago
When you rename an interface or a method, IDE renames them in tests too

dmitriid 4y ago

> But you should know this from your functional requirements, right? Functional requirements describe observable behaviour. You can't write any meaningful tests for that behaviour until a lot of your code is written. Yet somehow in all the discussions there's this unexplaned leap from "you have the requirements" -> "well you just write a unit test for your function first, and then code it". My functional requirements come in the form of "Given publisher A in Country B and contract requirements C the service must return D for a subset of products E", for multiple combinations of A, B, C, D, and E. And where each of those may and will require lookups in external services and databases.