3 ms·

TDD is good for features (like web apps) but not so much for algorithms. The difference is that you only need to support a tiny fraction of possible features /

• dnautics 6y ago
  I disagree. You code your algo for one input, come up with a corner case, write a failing test, refactor, repeat. For an algo, let's say it operates on a list, I'll start with test f([]) == 0, and implement f to output the constant 0. And then go from there.
  • bluGill 6y ago
    That only works if the algorithm isn't already understood and so you don't know what optimal is. If you tdd sort there is no way to get divide the list to small chunks, insert sort each small chunk, then merge sort them. (20 years ago this is what gnu sort did, I assume that this algorithm has changed now that cache is a bigger factor in performance). Even knowing that the above is your end goal TDD to get there is wrong because you don't know how the best algorithm will change when something else comes up as important. Tests are good, but they need to be universal for any implementation, which means you often cannot tests the internal details that prove you didn't use bogo sort (picking a pathological example to make the point)
    • dnautics 6y ago
      Ok but honestly, most people are not coding raw low level data structure algorithms. They are coding business algorithms. "Here's a table of accounts, calculate what they owe" When one says "wide range of inputs", as gp did, one is not talking about low-level algorithms; one is talking about a business algorithm. You should be using TDD for this.