Rumbling about Test Driven Development

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, with 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 questions often 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 a predefined set of requirements 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. I think TDD practice is mostly about that rather than writing tests first, although I can't recall anyone selling me on that particular advantage. It was mostly about tests first, correctness, code coverage, etc., and not a word about decomposition and focus.

Don't get me wrong, I'm a big fan of testing in general, and I think it does not really matter when you write it. As long as you have a set of acceptance criteria that you can ensure, usually with tests, then it doesn't matter if you write your tests before or after code.

Taken from a reddit comment, since I think the same: I think tests after are more natural and lead to cleaner code, so that's why I do it. As for the other developers I work with, give me good code with tests, and I don't care what order you wrote it in.

Rumbling about Test Driven Development

Recommended books