2 ms·

Is there irrefutable, objective proof that TDD is the one true way? I've looked into TDD but it simply does not fit my way of thinking and how I approach probl

• carlmr 8y ago
  >Is there irrefutable, objective proof that TDD is the one true way? No, there can never be irrefutable, objective proof for something that is a best practice. What you can do is check which teams are having the most bugs found by the customer, or how long they need to deliver that code, and then draw some statistical conclusions from it. In my (subjective) experience TDD a) gives you really good regression tests and b) makes you create smaller functions that are more easily testable and c) makes people think harder about their code. b) and c) aren't really effects on the tests, but because TDD drives this behavior (again, subjective experience) you get a better codebase, which in itself is of value. If you can get to that great codebase without TDD and write good regression tests catching all the edge cases post hoc, then you don't need TDD. >Especially for organically dogfood-development TDD is a bad methodology as you discover requirements as you go. Especially in this case I find TDD very helpful, because it provides a kind of executable documentation of the requirements you just discovered you want.
  • zaarn 8y ago
    >No, there can never be irrefutable, objective proof for something that is a best practice. That's rather begging the question, isn't it? There cannot be proof for the one true way since it's the one true way (or as you call it, best practise) >In my (subjective) experience TDD a) gives you really good regression tests and b) makes you create smaller functions that are more easily testable and c) makes people think harder about their code. In my experience, only when those people tended to do that beforehand. And b) and c) don't hold true in my experience either (people are happy to write big functions so their tests pass). c) is IMO not true either since it feels more like writing code to make tests pass not making code that fits requirements (unless you're good at writing requirements into tests but then why write code to tests code if you could write the code directly?) >Especially in this case I find TDD very helpful, because it provides a kind of executable documentation of the requirements you just discovered you want. That's not how that works. I'm sitting in the middle of a function, discovering requirements for that function while I'm writing it and running the application (ie, function does X but also should send an event to Y to clear the cache for user Z who triggered action X) When you don't have any fixed requirements, applications tend to evolve in-vitro, which doesn't mix well with TDD which is an pre-vitro.