A lesson learned is a lesson earned
How I learned to love TDD; and also what I learned and done these last two weeks.
--
Here’s the thing. I’ve always thought of Test Driven Development as a burden, slowing the development time of critical features that needed to be shipped as soon as possible. Well, it seems I’m not the only one thinking this way, just look at the interesting numbers in this article:
Nearly half of the respondents have not implemented a BDD/ATDD/TDD approach.
It seems there is a strong resentment among certain programmers to the idea of doing something that seems to be “useless” rather than doing what they like, writing code that works toward implementing features.
Well, after being forced to practice TDD in various course, including this related Software Project course I took, I think I have come to realize why there is such a strong cult trying to coerce this practice to devs. It seems like a chore and waste of time, but what if, maybe, instead, it was saving our time?
Consider the scenario where I was working to implement the feature: “Assign task to a sprint”. We hate TDD! Let’s just forget TDD for a moment and instead jump right to the code.
Let’s see.. it’s an easy task, we can just do this:
- Receive a message
- Parse Sprint name and Task name from the message
- Change task.sprint to the said sprint
Don’t need TDD just for that, eh? but wait, how do we separate Sprint Name and Task Name in the message? Should we have a separator or some sort? Well then let’s just whip up a regex, but how do we know if we parse it correctly? What if the Sprint with the said name can’t be find? What if this, what if that?
In my opinion, there’s too many branches and edge cases to handle in a single-pass coding session. If we force our way through this method we will have a, well, working code, but with many possibly unseen, missed flaws that can be fatal.
For a minute, let’s accept TDD. Here’s a snippet of the test I have written for one of the feature I worked in the last two weeks:
Technologies these days are such a wonder. Jest is such an amazing testing tools, who would have though I can test everything I wanted to? Hell, I can even mocks a setter of a property of an object of a mocked method in a module.
With this approach, I can just think of how I would want the function to behave, then state my expectations just right there in the test. I want the findOne method to exactly search for the name I thrown in the message, this ensure the regex captured the name correctly. And so on, and so forth. The plus is, I can even enhance my function requirements as I thought of it when throwing my expectations.
After writing the test, (then commiting a red commit). I can just follow the requirements I have truly understood, and the rest is easy as a pie. It became green in no time. Now I can just refactor as I want and voilá, I have a good, clean, working, flawless — well, I hope it was flawless — code.
This practice will also save time and resources in contrast when you deploy a bugged code into production and suffers. Consider TDD as an investment.
Appendix
Let’s end with some progress report of what I’ve done the last two weeks:
Sprint Entity
I have created a new entity (or model, table, you name it) to allow us to store information regarding the sprint itself. We missed it in the early database modelling phase, maybe because we think we won’t need it to create the MVP.
In short, I’ve created the entity class, defined what information it has (it only has a title attribute), and also created some many-to-one — one-to-many relations regarding the sprint to Task and Project. Then I’ve also created a migration to enable the database schema to be updated in every environment.
Create Sprint, Start Sprint, and Assign Task to Sprint
I have created the necessary command and logics to allow the user to create a sprint, then assign tasks to that sprint, and then start the sprint. In the process, I have learned a lot about mocking and in general, tests. Now TDD is not a burden anymore for me and I actually enjoy it.
And beside those tasks, like always, I have done some code reviews and also participate in the code-together event we created as an experiment to improve our future sprint.
