4 ms·

I don't think it's a parody, because I can see what he's getting at. If the programmer had written the "simpler" test first, he might have stumbled upon the al

I don't think it's a parody, because I can see what he's getting at. If the programmer had written the "simpler" test first, he might have stumbled upon the algorithm as illustrated without the false starts at the beginning, and then it would seem like more of a successful approach. Then again, I'm not sure how you're supposed to know which tests are the magic ones which will guide you to a solution, and the author conveniently trails off without telling us. (I'm also not sure what happened to first sitting down with a pen and paper and figuring out the algorithm, instead of praying to the TDD gods that you might magically stub your toe on it.)

Chris_Newton 16y ago
> Then again, I'm not sure how you're supposed to know which tests are the magic ones which will guide you to a solution, and the author conveniently trails off without telling us. Oh ye of little faith: you just do it the same way you know which magic refactorings to apply once your code is working, to turn your test-passing ad-hoc spaghetti into a clean, maintainable design. :-) > (I'm also not sure what happened to first sitting down with a pen and paper and figuring out the algorithm, instead of praying to the TDD gods that you might magically stub your toe on it.) Indeed. My current project for one client is building a user interface. I just spent nearly a week writing a design spec -- though some might call it a math paper -- to prove that all those transformations I'm planning to do to get from a user-friendly description of the situation to a hardware-friendly one are actually going to work. The TDD gods would no doubt consider me a heretic, but I suspect that I'll somehow avoid eternal damnation (as long as I write some tests later, of course).