I’ve been talking about Test Driven Development(TDD) practices in the past but I didn't give my opinion on that.

Unfortunately, I am not a big proponent of TDD.

It's probably because I haven't worked in places where it's been a serious part of the culture, haven't seen how it can work, and haven't found the motivation to rearrange my thinking accordingly.

Typically, on TDD, I do very simple things like transformation functions, validations, and so on, where the result is very deterministic and easy to code in tests. For more complicated things, I first make application design — draw components and try to fit them into concepts I understand, because complicated things don't sink into my head immediately without visualization. And often questions pop up. The most common one — is it even possible to do what I want to do, and when I get the answer to that question, there is a good chance that some part of the code has been already written.

From my personal experience, I've noticed that my greatest productivity in development has most to do with the clarity of the task. I always do not make the most complex or highest priority tasks first, but the simplest and most understandable ones. Even if they are large is size. I believe that this is the one of the greatest bottlenecks in the software engineering — understanding what the problem is.

It seems to me that the main benefit of TDD is not that you have code covered with tests before it's even written, but that the pre-defined set of conditions focuses the developer on solving a particular problem. It's great to keep your mind focused on what's important. Instead of procrastinating and thinking about where to start, what data structures to prepare, and so on, you pre-define the requirements literally to the result of the single function return. So decomposition doesn't happen during the task, it happens before the task.

Rather than tests, you can use a checklist on a piece of paper — the result, in the sense of focusing on small pieces of the solution, will be about the same. I think TDD practice is mostly about that, not about whether you have tests or not, although I can't recall anyone selling this exact advantage to people or me. It was mostly about correctness, code coverage, etc. etc., and not a word about decomposition and focus.

Recommended books