Test-Driven Development

Let’s continue our discussion of testing and ensuring the quality of our software processes by going in-depth with Test-Driven Development.

While this is a book about refactoring and Test-Driven Development is primarily intended for future development and bug fixing, it has some key lessons to teach us in software quality and the same tools Visual Studio provides to support Test-Driven Development can help immensely in the refactoring process.

In this chapter, we’ll cover the following main topics:

• What is Test-Driven Development?
• Test-Driven Development with Visual Studio
• When to use Test-Driven Development

Technical requirements

The starting code for this chapter is available from GitHub at https://github.com/PacktPublishing/Refactoring-with-CSharp in the Chapter07/Ch7BeginningCode folder.

What is Test-Driven Development?

Test-driven Development (TDD) is the process of writing your tests before you write your code for a new feature or to implement a new fix.

Under TDD, you first write a test for the feature you’re trying to implement or a test to reproduce the bug you’re about to fix. You do this in the most ideal way possible, which may even involve classes or methods that don’t exist at the start of your test.

Next, you do the minimum amount of work needed to make your code successfully compile. This isn’t to say that it runs perfectly or does the thing it is trying to do, in fact, you’re trying to start out with a red failing test that indicates your feature or fix doesn’t work.

This makes sense when you consider that at this point you haven’t implemented the new feature or made the fix to the code. So, the test should be a failing test.

Next, you write the minimum amount of code required to make your test...

Test-Driven Development with Visual Studio

We’re starting this chapter with a nearly empty console project and a supporting xUnit test project that has already been linked to the main project as shown in Chapter 6. The structure of this project can be seen in Figure 7.2:

Figure 7.2 – Solution Explorer showing only a few files

Over the course of the rest of this section, we’re going to add a new class to track frequent flier miles for Cloudy Skies Airlines.

The requirements we’ll be addressing (in order) are:

• When a new Frequent Flier Account is created it should start with a starting balance of 100 miles.
• You should be able to add miles to the frequent flier account.
• You should be able to mark miles as redeemed as long as this wouldn’t result in a negative balance.

These are not complex requirements, but they should serve as a starting point for briefly exploring TDD.

We’ll start with...

When to use Test-Driven Development

TDD is not always a good match for every task. Some tasks, such as highly visual user interface design may not fit into the TDD workflow very well, while others such as fixing an error observed in production or adding a new special case to a calculation are almost ideal for TDD.

Using TDD results in code that is generally easier to understand, has perfect or near-perfect code coverage on tests, and encourages refactoring along the way.

Many developers follow TDD but don’t follow it as strictly as outlined in this chapter. For example, instead of just generating a method, they may go ahead and implement the method and write additional argument validation code not required by their specific test.

Such deviations from TDD are common and often acceptable, though they usually result in a few pieces of code being added that don’t have supporting tests.

Ultimately, it’s up to you and your team to determine what works best...

Summary

In this chapter, we covered Test-Driven Development (TDD) and showed how its process involves writing only the minimum possible amount of code to get to a failing test – make that test pass with the minimum amount of code needed – then, refactor all code as needed before moving on to the next requirement or work item.

We also saw how Visual Studio has Quick Actions that allow you to generate types, properties, and methods and support your efforts in following TDD.

In the next chapter, we’ll talk about anti-patterns that can lead to unmaintainable code and SOLID principles that help your code be robust and maintainable.

Questions

1. What areas of your code would be a good fit for using TDD?
2. What areas might be harder to apply TDD to?

Further reading

You can find more information about materials discussed in this chapter at this URL:

• Test-Driven Development Walkthrough: https://learn.microsoft.com/en-us/visualstudio/test/quick-start-test-driven-development-with-test-explorer
• Is TDD Dead?: https://martinfowler.com/articles/is-tdd-dead/