The Intricacies of Rolling Out TDD

I have frequently seen developers putting their efforts into trying to convince the business to follow TDD or adopt unit tests. In fact, this is a situation in which I have often found myself, and for this reason, I want to share my experience with you in this chapter.

After reading this book, you might feel strongly about implementing TDD in your direct team or large organization to reap the quality benefits. So far, so good. The second stage is doing this in a structured manner and being prepared for the business’ counter-arguments and rejections.

We will highlight the challenges and guide you through the process of convincing your business and team to take the TDD approach. In this chapter, we will discuss the following topics:

• Technical challenges
• Team challenges
• Business challenges
• TDD arguments and misconceptions

After reading this chapter, you will be ready to present your team and/or business with a...

Technical challenges

There is a set of technical and business challenges an organization must overcome before adopting TDD. Here, we will cover the technical challenges, and in the next section, we will consider the team challenges and then the wider organization challenges (business challenges). We will start with a diagram to explain the workflow of rolling out TDD in your organization:

Figure 13.1 – Technical challenges when planning to move to TDD

We will go through the diagram in the next sub-sections, so let’s start.

Greenfield or brownfield?

If you are working on a brownfield project, the technical challenges were well presented in the previous chapter, so I will not go further into these challenges. To introduce TDD, you need to consider the effort, suitability, and alternatives.

If you are starting a new project (a greenfield project), then you are in luck. You can go ahead with your plan.

Tools and infrastructure

Today...

Team challenges

If you are a solo developer working on a project, no worries, you can do whatever. However, most business projects are implemented by a team, so making the effort to use TDD is a team decision. Again, let’s start with a workflow diagram:

Figure 13.2 – Team challenges when planning to move to TDD

We will go through this diagram in the next sub-sections. Let’s go through the points to keep in mind when planning to move your team – whether you are a developer wanting to influence the team or in a position where you can enforce technical standards.

Team experience

Unit testing requires DI, which in turn requires experience in OOP. Your team members may be unfamiliar with unit testing or may mistake unit testing with integration testing.

Important notes

The xUnit and NUnit libraries are widely used to implement integration tests. Because they have the suffix Unit, developers sometimes incorrectly assume the...

Business challenges

The business here means a higher technical authority outside the team, who can enforce rules. Also, it can be the project manager or the product owner.

I believe that a successful rollout of TDD or unit testing comes from top to bottom, management-wise. Enforcement can come from:

• Head of development
• Development manager
• Team lead
• Technical lead
• IT auditing

If this is a personal initiative or a team initiative, the team might think of dropping it under delivery pressure. However, if they are responsible for providing unit tests as part of the delivery, including a coverage level, then it cannot be missed.

Let’s think of TDD from the business perspective, so that we are better equipped and articulated in getting our points across.

Business benefits of TDD

We are well aware of what the benefits of TDD are from a technical point of view. But businesses would be more open to the benefits from the business point of view...

TDD arguments and misconceptions

Here are a few hints and tips – from my own experience – that will occur again and again in a conversation with the business or your colleagues.

Unit testing, not TDD

When discussing with the business, to reduce the complexity of the conversation, especially if the business is not tech-savvy, use the term unit testing rather than TDD. TDD is a technical process that individuals will do themselves and it is not directly related to the business, so why complicate the discussion by adding it? Sometimes the business has heard the term TDD, and they are excited about it, so then TDD is the right term to use!

My advice is to use unit testing in your conversation unless the business has some preference for the term TDD.

Unit testing is not implemented by testers

The term testing in unit testing is misleading to the non-techies as it implies a tester doing manual testing. I have had this conversation with many business individuals...

Summary

This chapter utilizes all the knowledge provided in this book and demonstrates the challenges of rolling out TDD into your organization. I hope I gave you enough arguments to convince the team and the business to subscribe to the TDD point of view.

Besides this chapter, your presentation skills and familiarity with the subject will be highly useful when planning to roll out TDD.

In this book, I have endeavored to provide practical examples of real frameworks and tools that I’ve worked with, rather than using abstract and oversimplified examples. I wrote the book out of love and passion for the topic and I tried to stay pragmatic, and I hope I delivered what I aimed to deliver.

While the title of this book refers to TDD, this book contains pragmatic examples of OOP and good programming practices, and by finishing the book, I trust you have stepped into the world of advanced software engineering.

Good luck and I would love to know how the book has contributed...