I like this discussion around problems that are hard or unsuited for TDD. I've tried to tackle numerical problems like an iterative root solver (ultimately via

I like this discussion around problems that are hard or unsuited for TDD. I've tried to tackle numerical problems like an iterative root solver (ultimately via a well-known algorithm like Newton's method) and it felt awkward. The tests around the output are either unrealistically constrained like "given this starting point, this function, and this number of iterations, have a floating point result within this precision" where I have to calculate those targets and tolerances by hand or have the completed algorithm I believe is already correct to get them. The progression of tests you would have are also non-trivial. I found myself spending more brainpower and time figuring out the "right test" than what I could do with confidence and a set of more traditional test cases. I think where it gets challenging is when you want a specific algorithm which in TDD is an "implementation detail" and against some of the core spirit spirit of the process of letting code naturally evolve. I also don't think that doing TDD should mean "you can't ever write Newton's algorithm". I settled on "write some reasonable tests around some sets of functions, iterations and/or tolerances", wrote some of the algorithm with very low level tests (which could have been made private which rubs me the wrong way too), kept that part of the code small, and wrote what I needed. That's basically been the philosophy I've seen in larger and reliable numerical packages. That doesn't mean I think TDD has "failed" and it's still my main choice when I'm hacking out something I want to live for more than a few hours. It's a useful tool, still has very broad application, but like anything with coding you need to pull out the tool for the job.