Over a million developers have joined DZone.

A TDD Challenge for Your Team

TDD is brilliant and yet a lot of people don't practice it for fear it will take too much time. Why not run this experiment to see if your fears are misplaced?

· DevOps Zone

The DevOps zone is brought to you in partnership with Sonatype Nexus. The Nexus suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

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 the 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 the 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 there's 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. In 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 the pros 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 teams in a place where they know how TDD in theory can improve development, but hesitate to do it in practice? If yes, then ask them to run a monthly experiment. Split your pull request into two parts. First to test and then to implement right 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 is about the test, then you will have to think what functionality it needs to have first.
  • More understandable in code review. Why? It is not so hard to understand one test. 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 an 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.

What Now?

Even if I didn’t fully convince you, you still should try! So many developers are already using TDD. So many of them can tell you about the values that TDD brings into the project. It's 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 for even longer. Good luck!

The DevOps zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today

java,spring,dependency injection

Published at DZone with permission of Sebastian Malaca, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}