[erdo]

I do TDD in one specific case, and it's always a unit test. Very occasionally I will need to write a function or a small class do some complicated logic that I'm too lazy or stupid to work out how to do. I do know exactly what the results should look like though, including all the possible edge cases.

( I think the last time I did this was for a point of sale terminal I was working on, which needed a solution similar to the change making problem https://en.m.wikipedia.org/wiki/Change-making_problem )

Anyway, for those situations, I write a large number of tests cases, covering every reasonable scenario, plus a bunch of unreasonable scenarios.

Then I write a half-assed implementation that fails on several tests, and I keep hacking about until more of the tests pass. Once they all pass, I stop. Even if at that point I have no idea why that particular version of the code completely works.

It's nasty I know, but sometimes it's the quickest way to a robust implementation