TDD IRL

I have a slight scepticism for anything that "drives" development other than the need to improve customers experience.

This is my take on TDD, once a year I write the tests first, I congratulate myself for solving the puzzle laid out in front of me, filling in the many gaps as I make the tests pass. Trouble is I actually prefer the joke acronym DDT where I write tests to protect my code which is the actual point of the tests.

DDT has no complexity, imagination, or room for interpretation, you test exactly what you have coded, that is quite efficient don't you think?

TTD involves guessing what tests you might need, the tests become pain points to refactor on top of your actual code, if requirements change / or being honest, you misunderstood something. you have to refactor both the test and the code.

In the world of interitive workflows, order matters, choose the path of least resistance, choose what makes sense.

Top comments (5)

Dan Silcox • Nov 6 '20

For me personally it's hugely helped to have TDD as the default even if I'm not actually religiously sticking to it 100% of the time.

In my experience, TDD is not meant to be "write all the tests up front" - it's about writing a todo list and then iterating through that list doing:

write a test / small, logical group of tests (e.g. testing some sort of filter with different values)
make that/those tests pass (write just enough code to do so, even if it's not DRY, perfectly factored, etc)
refactor the code (and the tests if they get too unwieldy) while keeping the tests passing
repeat with next item on to do list

I definitely don't want to come across as some sort of "gate keeper" or whatever - I just personally find TDD to be an extremely useful tool to save me from myself and help me think of the scenarios I need to code for, when combined with end-to-end tests that actually test the end user functionality.

That said, it does definitely take practice and can feel like a waste of time when you first start, but the amount of production issues I've been saved from by having unit tests and the amount of times when I've not TDD'd that I've then retrofitted tests and in so doing, found glaring bugs, both cause me to treat TDD as an absolutely vital tool in most cases.

I say most cases because for things where you don't really know what the code is going to look like, sometimes it is useful to just sort of write the code, figure out the details, then retro-fit the tests (and maybe comment out your code to prove your tests are actually testing your code!) - whatever's going to bring you as a developer - and the rest of your team / business (ie not just developers) - the most value long term really.

Adam Crockett 🌀 • Nov 6 '20

Hey man it's no problem, you didn't sound like a gate keeper at all, the post kind of expresses an opinion as did you and that's perfectly fine. Il take a full read as soon as I get a moment.