Dealing with Brownfield Projects

I cringe whenever I hear brownfield project, and probably you do too. Design decisions are already taken, code is already written by previous developers, and code quality varies between one class and another; brownfields are not for the faint-hearted.

As there could be multiple definitions for the term brownfield, I want to start by defining it here, so we are all on the same page. From this book’s perspective, a brownfield project is a project not covered by unit tests and was probably written a while ago. It might have been covered by other types of tests than unit tests, but we will still refer to it as a brownfield. Some techies also refer to it as a legacy project.

As you have already figured out, we have dedicated a whole chapter to brownfields as there are challenges in introducing TDD or unit testing to such projects. We will discuss those challenges and how to overcome them.

In this chapter, we will cover the following topics...

Technical requirements

The code for this chapter can be found at the following GitHub repository:

https://github.com/PacktPublishing/Pragmatic-Test-Driven-Development-in-C-Sharp-and-.NET/tree/main/ch12

Analyzing the challenges

In the previous chapters, we’ve been talking about adding new features while starting from the unit tests end (testing first). We relied on having a new functionality or modifying an existing functionality that is already covered by existing unit tests. This is not the case for brownfields as, when trying to apply TDD, you will face some of these challenges:

• Dependency injection support: Some legacy frameworks do not natively support DI, which is necessary for unit tests.
• Code modification challenges: Changes to code that are not covered by tests (of any type) can introduce new bugs.
• Time and effort challenges: Introducing the ability to unit test the code requires time and effort.

Let’s go through each challenge in detail, so you can consider them when the time comes.

Dependency injection support

In this book, before learning about unit testing or TDD, we had to introduce DI. DI is what allows you to separate your...

The strategy of enabling TDD

Now is the time to discuss solutions to the challenges described in the previous section. Since a picture is worth a thousand words, I will present a workflow diagram that should clarify how to introduce unit testing into a brownfield project:

Figure 12.1 – The workflow of enabling TDD in a project

Let’s go through the diagram and our options.

Consider rewriting

You might consider rewriting because the existing project might be based on an old framework with fewer developers and less support. However, the rewriting idea is controversial. If you tell the business that the project requires rewriting, you will be their least favorite individual. Trust me; nobody wants to hear this. However, good rewriting doesn’t need to be a big bang; it can be divided into smaller chunks of upgrades and can be appended to sprints. Obviously, choosing a modern framework that supports DI natively or through a third party...

Refactoring for unit testing

When you write in TDD, your code is unit testable from the first moment. This is because you took into consideration DI scenarios. Brownfield code almost always has no consideration for DI, and it will have to change to accommodate it.

In this section, we will cover the scenarios that you have to change, and then we will go through an example of a sample refactoring at the end of this section.

Variables instantiated in the code

Whenever you see a new keyword in the code that is instantiating a library or a service, then most probably, this needs refactoring. Take the following example of code in a method:

var obj = new Foo();
obj.DoBar();

The previous line means we cannot inject a test double for Foo, so the code needs to change to inject it.

The next thing to do is to check whether Foo implements an interface for the methods you are using from this class. Let me break the bad news for you here – keep your expectations low; you...

Summary

In this chapter, we discussed the implications of enabling unit testing for a brownfield project. We’ve gone through the considerations to allow you to decide whether it is worth it and all the things that you have to watch for while progressing with the process.

As a developer, you will encounter brownfield projects that went up in value and would benefit from unit tests and TDD. Hopefully, this chapter equipped you with the required knowledge to tackle them.

Deciding to introduce TDD into your organization is not a straightforward process. The next chapter will go through the process and prepare you for some scenarios that you would face.

Further reading 

To learn more about the topics discussed in the chapter, you can refer to the following links: 

• JustMock (Isolation Framework from Telerik): https://docs.telerik.com/devtools/justmock
• Microsoft Fakes (Isolation Framework that comes with VS Enterprise): https://docs.microsoft.com/en-us/visualstudio/test/isolating-code-under-test-with-microsoft-fakes
• TypeMock (Isolation Framework for classical .NET Framework): https://www.typemock.com