Test-Driven Development Explained

Test-Driven Development (TDD) is a set of practices on top of unit tests. They alter the way you design your code and you write unit tests. Basically, it is a different approach to writing code than the classical technique of writing code and then testing it after.

It is a cliché to say that TDD is not just doing testing first, but rather than me telling you otherwise, you will decide yourself after going through Chapters 5 and 6.

In this chapter, we will:

• Go through TDD pillars
• Implement a software feature following the TDD style
• Converse the FAQs and criticism around the subject
• Discuss having TDD with Sintegration testing

By the end of the chapter, you will be able to use TDD to write basic coding tasks and understand the topics around the subject and where TDD fits in the software ecosystem.

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/ch05

TDD pillars

TDD is a set of practices that specify how and when a unit test should be written. You can write unit tests without TDD, but TDD has to have a type of test associated with it. Sometimes, you can hear TDD and unit tests used as if they mean the same thing, but they are not.

While the ecosystem around TDD is sophisticated as it touches a lot of software engineering aspects, TDD as a standalone concept is easy to explain and understand. We can summarize TDD as these two pillars:

• Test first
• Red, Green, Refactor (RGR)

Let’s discuss these pillars.

Test first

The idea here is to start with the tests before starting with the production code. It really means testing code that doesn’t exist yet!

Testing first changes the way we write code, as now you are redirected to think about your classes' structure and public methods before the implementation. This encourages the developer to reflect on the design from the client’s perspective...

TDD by example

TDD is best understood by looking at examples, so let’s take a story and write it TDD-style. We will be working on the feature described by this story:

Story Title:

Changing a username

Story Description:

As a customer

Given I already have an account

When I navigate to my profile page

Then I can update my username

Acceptance Criteria:

The username can only contain between 8 and 12 characters, inclusive:

- Valid: AnameOf8, NameOfChar12

- Invalid: AnameOfChar13, NameOf7

Only alphanumerics and underscores are allowed:

- Valid: Letter_123

- Invalid: !The_Start, InThe@Middle, WithDollar$, Space 123

If the username already exists, generate an error

Let’s not waste any time and implement this story.

Creating the solution shell

We will create a class library called Uqs.Customer, add a unit testing project to test it called Uqs.Customer.Tests.Unit, and add them to a solution called TddByExample.sln. So, let’...

FAQs and criticism

TDD is one of the most controversial topics in modern software development. You will find some developers swearing by it and others claiming it is useless.

I will try to objectively answer the questions and show you both views where relevant.

Why do I need to do TDD? Can’t I just do unit testing?

As you’ve gathered from the start of the chapter, TDD is a style of writing unit tests. So, yes, you can write unit tests without following the TDD style. In the next chapter, you will find the first guideline from the FIRSTHAND guidelines that will focus on the benefits of following the TDD style.

I found that some teams are reluctant to do TDD for various reasons. My recommendation is not to abandon unit tests in case your team is not inclined to follow TDD. Maybe if you start with unit testing, then the next evolution would be TDD. This would slow down the rate of change for some teams.

Did I say this before? Don’t abandon unit testing...

TDD with Sintegration tests

One criticism of unit testing is that the unit test code will be tightly coupled with the implementation. Changing production code will have a rippling effect that will force updating, adding, and removing multiple unit tests.

These are ways to reduce coupling with unit tests, which are discussed in Chapter 6, The FIRSTHAND Guidelines of TDD, in The single-behavior guideline section. However, the provided solutions do reduce coupling but don’t get rid of them completely.

On the other hand, integration tests have a dependency on the input and output of the tested functionality. If we are doing integration testing for an API, then we are concerned about what parameters we pass to the API and what we get back, that is, the input and output. This creates loose coupling with the code. Here is a reminder of how integration testing and unit testing operate:

Figure 5.9 – Integration tests versus unit tests

As you can...

Summary

We’ve been through the basics and the principles around TDD, thus, I trust that at this point, you can confidently describe the process to a colleague. However, this chapter is the start of learning TDD, as the book will continue adding to your knowledge as you go.

I held my pen (okay, my keyboard) back from writing more advanced examples and stopped here for a smoother introduction. I hope that I explained the concept in a clear way and encouraged you to continue the book, as the upcoming chapters will have more pragmatic examples that will give you the experience to apply TDD in your own project.

In the next chapter, we will discuss the TDD guidelines and what I refer to as the FIRSTHAND guidelines. You will understand why testing first is important and what value it offers you.

Further reading

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

• Martin Fowler on Test-Driven Development: https://martinfowler.com/bliki/TestDrivenDevelopment.html
• Extreme Programming: https://www.agilealliance.org/glossary/xp
• Classic TDD or “London School”?: http://codemanship.co.uk/parlezuml/blog/?postid=987