Ok first of all, thank you for no puns, the only one making bad puns in here is me and if you disagree, fight me. Second, I just barfed up a novel of a comment at poor sebastian, so I’ll paraphrase here:

The person DID know TDD. The feature WAS simple. It was a function that read a feature flag. Things got hairy when we realized both the underlying flag and product request were faulty. This led to a total change of plans, meaning the half an hour we took to write tests was wasted since the solution would be completely different. I argue if we had been allowed to plan, then explore without trying to set a test in stone, we would’ve learned without wasting more time.

Phew. Thirdly. Yea I get it and agree. TDD is the bomb dot com, except for that first T. I love pretty much everything about it. The planning. The strategy. The whole 8 yards, because the last yard is actually coding a test. Which, as I have stated, forces you to kind of guess sometimes, and I just don’t think you need to. Becuase if you don’t waste time on tests, when things you thought you knew turn out to be false, there is literally no time wasted or harm done. We thought we knew what we wanted, but like a the protagonist in a terrible rom com, we actually did not. And becuase we tried to write tests, we were penalized. Sticking to the rom com, we were forcing ourselves to try and make it work with our schlubby mate before realizing we should’ve just been with Will Smith the whole time.

TDD is a beautiful diamond set on a Ring Pop. I love everything about it except for the part where you write the test. Verbally plan it, keep it in mind when you code, use the parameters for the hypothetical test when you do first round manual testing. Just don’t put code to IDE on the test until you have your function.

This was slightly more of a novel than I was hoping for, but there it is. And thank you for politely disagreeing with me and not just calling me a moron haha