I admit it; I used to hate testing. It never made any sense. Why would I want to write more code (test code, that is) when I already have code to write?
With time (and many years of force by the industry), I have learned to understand its importance and place in a software project. However, I have also learned to understand its abuse.
Let's take a look at a practice that is commonly abused, TDD.
TDD: the "poster child" of software development
What is TDD?
Another method that developers made to help you code slower and miss deadlines more often. TDD stands for Test-Driven Doom, oh wait, I mean Test-Driven Development, and it's all about telling you how your code is wrong and how you can stop whatever you are doing to make sure you are writing code correctly.
First off, you may think that the first objective is to write code, but really, your first objective is to write test code for code you haven't written yet. That is the proper way to write code.
Then after you write that code, make sure that the code doesn't pass. If it passes on first run, you are definitely doing it wrong. In fact, if it compiles on the first run you are one confused individual. You have to make sure it doesn't pass. Then you write the code for the test code you wrote earlier, then keep writing and correcting the code until it passes — then, and only then, have you completed TDD.
Of course, I'm being hyperbolic here, but you see my point.
The problem with TDD
So as you may have noticed, TDD is not my cup of tea. It has a few shortcomings:
- It is recommended for every project. I don't even think I'm exaggerating. Every senior developer swears that it works for every project (and can cure cancer) and I can testify that that's not true. Never have I looked at a failed project of mine and said, "Yup, this project would have been much better using TDD."
- It stifles tinkering, imagination and exploration. It causes me to do a lot of upfront thinking, which is not always a bad thing. However, if I'm dabbling into projects that I'm not too familiar with or I'm not sure of the full direction, I want to plan what I can plan on paper, then code at my computer. That way, I can just jump into code when I get on my computer.
- They claim it helps you to know how to start your project. However, in my experience, you have to do this for every project you ever encounter: you have to determine what code to write first. You don't need TDD to do this.
- They claim that it enforces good practices. I don't like the term "enforces" in this context. I believe every developer should have the freedom to do whatever they want to do when developing. And as for "good practices"; what encourages good practices is extensive coding i.e. you must code to be better at coding.
But still, I use TDD...
It's ironic, I know. But sometimes it works. Just not every time.
TDD purists would swear up and down that they always use TDD and follow the laws of programming to the T.
But let's be honest: the importance of practices like TDD are nowhere close to that of other practices and philosophies like KISS (Keep It Simple Stupid), SOLID, or even YAGNI (You Ain't Gonna Need It).
...but most times I don't
TDD is bad when it gets in the way of tinkering.
There are times when I'm writing experimental code. Writing test code for experimental code is not wise as the code may be deleted later.
I consider most of the code I write as experimental; I don't know the final structure I would choose when I start writing code. Most times I just plan on paper and just jump into code right after: I don't see why I should do otherwise.
I'm not saying that you should not plan when writing code. I'm just saying that it is okay to not use TDD. Sometimes, I even write the tests after I finished writing the code.
I guess the main problem with TDD for me is that I have to write test code for code that I'm not sure is going to stay in the project. That's way more code than I'm willing to write.
What is the alternative?
Simple. Write the code first, then write the test code. A foolproof solution that has been working for years for me. That way when I do write test code, it's more likely to stay in the codebase.
(I know, TDD purists would argue I deserve death by lethal injection for making such a claim but they're have to catch me first! 🙃)
The bottom line
I use TDD when:
- I already know exactly how the resulting API should look.
- I'm in a corporate setting, where a lot of planning is done ahead of time.
- I know how the new code would interact with the current codebase.
- I'm adding features to an existing codebase (especially one where some tests have already been written).
I don't when:
- I'm tinkering.
- I want to be free and control how I write my software (which is almost always).
In conclusion, don't let anyone tell you how to write code. Hone your craft; choose the practices that work for you.