Jurann MacRae
Aug 18 · 2 min read

26 year principal/architect software engineer here - you’ve learned the dirty secret of TDD, congratulations. It’s a pipe dream and does nothing but get in the way of getting actual work done. “Unit Tests After Dev” (UTAD) should be the standard, not TDD. The former costs you very little time and effort while the latter adds easily 40–60% more development time to any project and makes it more confusing. I worked at two places where TDD was absolutely mandatory, and burned out at both places within 6 months from tedium and the drudgery as well — it’s not just slow and tedious, but it completely kills your desire to make progress and deliver a product. If unit tests are so important, then companies should be hiring SDETs to do them, not asking the feature engineers to be writing tests for their own code. I think you’ll find that most places who CLAIM they are using TDD actually aren’t, because at the end of the day it’s engineers who write the code, and it’s engineers who enforce the code as well — none of us want to be doing TDD so we have a more or less unspoken rule that we don’t. It’s a waste of effort.

All that said, I’m 100% for outlining your functions before you write a single line of code, and it’s a practice I’ve been using since college (23 years ago). It’s pretty simple, you just create your function skeleton and then add comment lines inside explaining what you want/need to do inside the function, and once you have the whole outline you just fill in the code between comments with the code to do what the comments are explaining. Leave the comments there for the next dev to understand the thinking and process. Everyone wins and you come out with cleaner, more methodical, well-thought-out code.

    Jurann MacRae

    Written by