DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Testing, Tools, and Frameworks
  4. I Tried Test-Driven Development for A Month and Survived

I Tried Test-Driven Development for A Month and Survived

One developer recounts his initial resistance, learning, and acceptance of test-driven development, as well as some of the benefits TDD offers.

Leon Bezuidenhout user avatar by
Leon Bezuidenhout
·
Jan. 15, 20 · Opinion
Like (4)
Save
Tweet
Share
10.24K Views

Join the DZone community and get the full member experience.

Join For Free

What doesn't kill you makes you stronger, and your tests pass.

When I first heard about Test-Driven Development (TDD) I immediately wrote it off as a technique that would slow me down. How on Earth should I know exactly what my code will look like if I often refactor while coding? Besides, I’ve been coding for many years and understand how to write code that is “easily” testable. For me, it made perfect sense to ignore this crazy idea.

Then I realized TDD doesn’t mean what I thought it meant. The first time TDD was explained to me many years ago, I was told, “You write all your unit tests first” and that is what stuck with me. Even now when I ask developers what they understand about TDD that is the response I receive.

So What is TDD?

Test-Driven Development is an iterative programming workflow whereby you write a single unit test and then write the code, if required, to make the test pass. When the test passes, you refactor your code, including the tests, before writing the next test.

There are more complete definitions available, but I have found that this is a sufficient definition to start a conversation when developers first encounter the principle.

You may also enjoy: 4 Tips for Adopting Test-Driven Development (TDD) 

How to Practice TDD

What convinced me to try TDD was reading The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin (Uncle Bob). The book dedicates a chapter to TDD and another chapter on practicing TDD where there is mention of a Bowling Game Code Kata that Uncle Bob uses for demonstrations of TDD. Finding this demonstration online and following it was the introduction to TDD I have been missing. Try it for yourself and then try to apply the workflow to a small problem of your own with a known solution.

Advantages of TDD

This is what I found during a month of practicing TDD in different contexts.

It’s Strangely Natural

Since I started the practice of writing unit tests earlier in my career, whenever I found a bug that did not have a test I would create a new test to reproduce the bug first and only then change the program code until I had a green build again. Turns out I have been doing TDD for bugs all along.

It Can Be Engaging

There was time when writing the unit tests were a lot more interesting than writing the feature code. TDD offers a unique way to make your journey through less interesting code more rewarding.

It’s a Good Way to Pick up An Old Toolset

It’s been a while since I wrote Java when I started again the first thing I did was a code kata to try TDD. It forced me to immediately consider the tools needed for testing, rather than get stuck at the end. The number of times I have told a manager that everything is going according to schedule only to be derailed by unit test tools at the end of a long day when the pressure was on to deliver is probably higher than I’d care to admit.

It’s a Great Way to Learn a New Language

“Hello world” is the staple of starting a new programming language, but perhaps it does not add enough value for developers who have been coding for many years. Consider this Python program.

Python
x
 
1
print(“Hello world!”)

Perhaps we could learn more about a new programming language if our first application was:

Python




xxxxxxxxxx
1
10


 
1
import hello
2
import unittest
3
4
class TestHello(unittest.TestCase):
5
    def test_hello(self):
6
        result = hello.hello_world()
7
        self.assertEqual(result, 'Hello world!')
8
9
if __name__ == '__main__':
10
    unittest.main()



Python
 




x


 
1
def hello_world():
2
    return "Hello world!"


It Improves Design

Every time a developer says they don’t know how to test a piece of functionality I assume it is a design problem, and often it is. Even with my own code I’ve had to refactor many times when I started writing tests, because some paths were difficult to test. TDD addresses this by making refactoring part of your development cycle.

It Improves Estimates

The number of teams I still encounter who do not write unit tests and rely completely on manual tests is weirdly high. When these teams start writing tests I find that their estimates can be overly optimistic. Forcing you to think about the tests you will be writing during feature development rather than it being “something you do at the end” helps you mentally keep the whole process in your head.

It’s Excellent for Pair Programming

With ping-pong pair programming two developers work together at the same PC. Developer A writes a failing unit test and then Developer B writes the code to make the test pass. Developer B will then write the next failing unit test and Developer A will write the code to make the test pass. It’s a fun way to challenge each other during pair programming and an excellent tool for teaching when a senior and junior developer pairs.

When the Feature Is Complete, so Are Your Unit Tests

This goes without saying, but it feels so satisfying when your tests are completed when you have finished your last bit of feature code. Maybe a bug will be found later, but you will always write the test before proceeding to write more feature code.

Final Thoughts

With information being freely available we are in a unique position to learn from people without ever having met them. In my case, Uncle Bob helped me understand TDD and try it in a safe, zero consequence environment, and it turned out I enjoy TDD.

We should always be trying new ideas and decide if we want it to be part of our workflow. The important thing is to try it for long enough to form an unbiased opinion.

Further Reading

Why Developers Don't Use TDD

TDD Example in Software Development (Part I)

unit test Test-driven development Software development

Published at DZone with permission of Leon Bezuidenhout. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • The 12 Biggest Android App Development Trends in 2023
  • How to Secure Your CI/CD Pipeline
  • Cloud Native London Meetup: 3 Pitfalls Everyone Should Avoid With Cloud Data
  • Handling Automatic ID Generation in PostgreSQL With Node.js and Sequelize

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: