Test-Driven Development is a great technique, isn’t it? Today I want to propose you an experiment that may help you convince all of those struggling developers that writing code in such manner really improves your code and development.
What is the experiment about? It’s about only one, tiny commit which will force you to practice this technique for some time. Talk with your team/teams and propose a new way of doing pull requests.
The first commit for test, the second for implementation. Easy, isn’t it?
TDD – yes or no?
As I wrote, Test-Driven Development is a great technique. It makes our code easier to maintain and develop and, at the same time, it makes introducing a change into a code far less scary. Yet, even if most of the developers I know would agree with me on this, I also know that many of them do TDD only when it comes to interviewing a candidate. In reality, they write tests just after writing code. The purpose of those tests is not to be a design driver, but to satisfy coverage.
Why is that? I don’t know all reasons, but there’s one explanation that I hear really often: “because it is faster to write code without TDD”.
Why is it faster? Because of not enough practice.
How can we change it? By practicing. By practicing a lot. By practicing on a daily basis.
Why aren’t we practicing? Because we are already experienced in writing code in a different manner. At the beginning a new technique will slow us down. And we don’t have time to be slowed down.
On the other hand, the same developers agree that this technique is valuable. Many of them can list all prons that TDD gives us. They can tell something about positive impact of it on the code design.
Well, in that case, something is really wrong.
Challenge accepted?
This is the moment when we can go back to the experiment that I proposed at the beginning.
Are your team/teams in the place when they know how TDD in theory can improve their development, but they hesitate to do it in practice? If yes, then ask them to run a monthly experiment. Split your pull request into two parts. First test and implementation just after.
The history of the commit will reflect your TDD-oriented approach.
It would also make it easier for a new developer to learn how to write code in the same manner.
Challenge accepted?
Why can it work?
There are a few benefits of running this experiment:
- You are practicing. Whether you like it or not, your code will be test-driven. You will have a great chance to learn how it works in the real world.
- You will be expectation-oriented. There won’t be even a possibility to make it different. If a first commit were about the test, then you would have to first think what functionality it needs to do.
- More understandable in code review. Why? It is not so hard to understand one test. And when a reviewer knows what requirements the implementation has to fulfil, the review of the second commit will be far more easier. Even if you would have to create a few new classes and write unit tests for them. This complexity will come in the second commit.
- You split “What” from “How”. Your code base will be documented even better, because for each commit you will have another one that will tell you exactly what is important.
Yet, to be honest you can expect one negative thing that can be used as an argument against the experiment. At the beginning the development will slow down. This happens whenever you are learning something new. Before you reach mastery, before it becomes a habit, you would have to put additional effort into this activity. Why? Because it would be so much different from what you were doing till now.
But remember – this is investment! Your code will have better documentation. Its design will be improved. You will focus on “What” not “How” and this approach usually makes code simpler, there’ are no additional lines of code.
What’s now?
Even if I didn’t fully convince you, you still should try!
So many developers are already using TDD. So many of them tell about values that TDD brings into the project.
And this is only a month, isn’t it? How can it harm you?
Yet, there are so many things it can improve!
After all, maybe you would like to use this approach even for longer.
Good luck!
| Reference: | First for test, second for implementation! from our JCG partner Sebastian Malaca at the Let’s talk about Java blog. |
