13

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 plan to move forward with TDD.

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, with the availability of the cloud, having an infrastructure to run your continuous integration (CI) pipeline is easy and cheap. However, some organizations have restrictions on using the cloud and you might struggle to get a CI server.

If you don’t have a CI server in place, then at the risk of sounding pessimistic, doing TDD is doomed to fail. This is because developers will break the unit tests and you will have them disabled or failing.

Some developers also like to invest in tools such as JetBrains ReSharper for its good-quality test runner and refactoring capabilities, but this is optional. Also, you may want to consider JetBrains Rider as it has all the capabilities of ReSharper, as discussed in Chapter 1 of this book.

However, if you are using MS Visual Studio Professional 2022 or later, you already have a good tool for a proper TDD process.

The technical challenges are not all you need to think about. Consider also your team and its readiness to embrace TDD and then your business challenges. Let’s continue with the team challenges.

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 written tests are unit tests. I’ve seen teams claiming they have unit tests, but when I inspected the code, I discovered otherwise.

If your team requires training in TDD, then they need to be educated on what it is, how to do it, and the value of TDD. I have a book in mind to recommend for the training, but I will leave it to you to guess which it is.

Important notes

I usually ask the team to read certain material on their own before having a session or several sessions on the topic. Training a team can be done in many ways, and it is more related to your company and team culture. I also document the conventions and the agreement on Confluence or whatever tool the organization uses for documentation.

It is important to have a competent developer in the team, who understands unit testing, is a good explainer, and can squeeze in some time, which could be you. This would be helpful, as your team will have questions when they start TDD.

But training the team may not be an option for many reasons. Having a few members of the team doing unit testing and others not won’t be productive, as everyone is going to operate on the same code base, so having everybody trained and ready for TDD is a prerequisite.

Willingness

Some teams are not willing to do unit testing whether they feel it is difficult or increases development time or they don’t perceive the value.

Important notes

I have seen unit testing enforced by an organization, but the team was unwilling to write the tests, and they just created a unit test project with meaningless tests to tick the box of the question Have you implemented unit testing?.

Having the team synchronized with the objective and collaborating for one goal is valuable in promoting product quality.

If your team is not willing to go for TDD for whatever reason but unit testing is OK, then go for it! You can gently introduce TDD soon after. It doesn’t need to be all or nothing. It is also worth noting that some members can do TDD while others can do unit tests.

Unit testing is useless

I have heard this argument from many developers. They might have formed their opinion on bad implementations of unit testing or have other reasons. Certainly, unit testing has some disadvantages, but so do most technologies.

Your best shot is to understand the reasons behind this misconception and see whether you can address them.

TDD is useless, I would do unit testing

TDD is controversial and sometimes developers have their own experiences that told them that TDD is unusable. This is OK as long as they are happy with unit testing because not all team members have to do TDD.

If the developers who don’t believe in unit tests are building their arguments on seeing bad practices, then your job might be to promote good practices.

The team’s willingness to follow TDD has a crucial impact on the success of the project, so it is important to have everybody on the same page.

Timing

TDD requires some preparations and extra effort to get the essential quality, following the no pain, no gain mantra. Having the right time is important and it should definitely not be near the release time or when the team is stressed.

The perfect time is at the start of the project, but there is no harm in introducing it later.

Once you’ve passed the first and second challenges, you will have the business challenges, which are arguably the hardest.

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, so let’s get into it.

Fewer bugs

This is clearly the biggest seller, as nobody likes bugs. Some businesses are stung by a high number of defects in their products, and having less is definitely a welcome promise.

The only issue is that it is hard to prove a lower number of bugs via statistics – the project will have unit tests from day one, so we can’t make a comparison between before and after.

Live documentation for the project

One thing that worries the business is documentation, which has a tight relationship with developers’ turnover. The risk is that if a developer leaves, some of the business knowledge is lost. To prevent this situation, it is important to have the business rules robustly documented, and, in all honesty, I can’t think of any tool that is better for this than unit tests.

Project documentation contains documents that cannot be covered by unit tests, such as project architecture. However, the detailed business rules that nobody will remember in a few months will be covered by unit tests and monitored with every developer source control push.

Promoting unit testing as a documentation tool is powerful and will give you listening ears from the business.

Fewer testing resources

In the old days, manual testing took a good chunk of the software development life cycle (SDLC). Today, with unit tests and other automated tests, manual testing has shrunk in size and the number of required manual testers has gone down. Some organizations have even eliminated manual testing completely in favor of having automated tests (including unit tests).

So, the promise of unit tests is about covering lots of edge cases and business rules with fewer testers and almost no regression test time.

Important note

Regression testing is going through existing functionality to ensure it is still working. This typically happens before a new release.

Obviously, fewer testing resources means less cost, while less time means shipping a feature faster, which naturally leads us to the next topic.

Ability to release in short cycles

The development model today in more agile organizations has moved to shipping a few features now and then.

Having unit tests regressing the code with every change and a CI/CD system in place means your software is ready to be shipped anytime.

No clever business person will believe all these aforementioned benefits will come at no cost, so next, we will discuss the disadvantages of unit testing.

Disadvantages from the business perspective

In general, extra quality requires more effort, and TDD is no different, but luckily the disadvantages are minimal.

Slight delay in the first release

We have discussed before that teams not using TDD tend to deliver faster in the first period; we have spoken about this in Chapter 5, Test-Driven Development Explained. Here is a quick reminder:

Figure 13.3 – TDD versus no unit testing

The idea here is that the effort of writing unit tests adds to the development time in the short term, but the speed becomes faster in the mid and long terms.

This is a small price to pay for quality, but just be aware of this point.

Delay in the first release is not acceptable

There are circumstances where the business wants the first version as soon as possible and they are not interested in looking beyond this. Here are a few scenarios:

• The product manager wants the first version out as soon as possible, as this can lead them to get a higher bonus or a promotion.
• There is a competitive advantage in releasing as soon as possible and not worrying about the future. This is the mentality of a start-up trying to survive.
• This project is done for a third party, and the business doesn’t get paid extra for ensuring added quality. But getting this in the shortest time possible is the intention.

It would be clear if the business is not interested, and you can feel this in advance if you know the business model that the company uses. This is not a criticism against TDD, but it would become a disadvantage when mixed with such scenarios.

Now that we have gone through all the challenges and the merits of TDD, let’s form a plan to introduce TDD.

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.

It is important to clarify that unit testing has more functionality other than just testing, such as the following:

• Shaping the code design architecture of the project
• Live documenting the code
• Instant feedback during development when breaking a business rule

Also, unit tests are written in C# (or whatever other language you are using), and they are implemented by the same developer writing the code. A manual tester, most probably, won’t have the willingness or the expertise to write these tests.

This argument might be triggered when the business is wondering why you want to consume the engineers’ expensive time on unit testing when there are testers that could (as they initially thought) do the unit tests.

The way for writing and maintaining documentation

I am sure experienced business people will relate to the lack of documentation or the documentation becoming out of date.

As you already know, documenting the code with unit tests provides fresh documentation versus text-based stale documentation that is written and forgotten or covers part of the system (a hit and a miss). The keyword here is up-to-date, fresh, or live. Obviously, we are talking about part of the documentation and you might have to make this clear. This is the detailed business rules part.

We have incompetent developers

Businesses sometimes believe they have incompetent developers, and this is why they are producing plenty of bugs. I have heard this argument whispered by the business on multiple occasions when talking about their team.

When I hear this argument, I quickly dig and discover that the business does not have a structure in place for the agile process and that the developers are rewarded for how fast they finish developing a feature. We all know that person who takes the shortest route to get their features done and show off to the business!

Developers are highly logical individuals who like structure and order. Having a development process with TDD will definitely reduce bugs and set things on track.

Your challenge here is to show how the TDD process and the tests will have a positive effect on the problem.

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 to you or your team adopting TDD.