The book covers everything from why TDD is important to setting up testing environments, and how to get started testing a green-field application. As the reader grows more comfortable, they will be exposed to more advanced TDD topics such as abstracting away third-party code, approaching a problem from a TDD perspective, and how to deal with legacy code that wasn't written with testability in mind.
Chapter 1, Why TDD is Important, asks what is TDD and why should you care? In this chapter, you will learn what TDD is and why it matters. A compelling argument for TDD will be made and the benefits, and more importantly, the execution will be shown.
Chapter 2, Setting Up the .NET Test Environment, explains how to set up your IDE and configure the testing framework so that you can easily run your tests in C# and .NET, with more detail and many more examples of growing complexity in the Speaker Meet API.
Chapter 3, Setting Up a JavaScript Environment, configures the JavaScript testing framework so that you can easily run your tests in your IDE. It provides more detail and many more examples of growing complexity in the Speaker Meet React application.
Chapter 4, What to Know Before Getting Started, dives deeper into the why and how of TDD. you will learn the importance of defining and testing boundaries and abstracting away third-party code (including the .NET Framework), and you'll discover more advanced concepts such as spies, mocks, and fakes, and how to avoid pitfalls along the way.
Chapter 5, Tabula Rasa - Approaching an Application with TDD in Mind, explains how to get started with a new application. You'll apply what you've learned in the previous chapters and take the same approach with a full-sized application using Speaker Meet as an example.
Chapter 6, Approaching the Problem, takes the broader problem of the overall application and breaks it into meaningful chunks that can be developed independently. You'll learn different approaches to developing an application, such as front to back, back to front, and inside out.
Chapter 7, Test-Driving C# Applications, takes requirements and assembled user stories and turns them into working software using TDD. It explains how to utilize all the skills you've assembled so far to test the boundaries, testing small, individual units.
Chapter 8, Abstract Away Problems, explores abstracting away third-party libraries, including the .NET Framework. It covers removing dependencies on things such as DateTime and Entity Framework. It explains how to decouple their application from specific implementations to not only allow your application to be testable but much more flexible and easy to modify in the future.
Chapter 9, Testing JavaScript Applications, now that you have a working API, focuses on creating a Single Page Application in JavaScript using React. It focuses on test-driven actions and reducers and any functionality within the application.
Chapter 10, Exploring Integrations, explains how to write integration tests to ensure that your application is functioning properly.
Chapter 11, Changes in Requirements, focuses on what happens when the requirements change. What happens if a bug is discovered? No problem, change a test or write a new one to cover the new requirement or to defend against the discovered bug. Now, write some new code or change some existing code to make all of the new/modified tests pass. If you do everything correctly, you should feel safe to make these changes as your existing test suite will prevent you from introducing new bugs.
Chapter 12, The Legacy Problem, explains that there are a lot of applications out there without sufficient (any?) test coverage, and even fewer were written test-first. You'll discover some of the major problems with legacy applications that weren't written with testability in mind; they will be identified, and also how best to recover will be covered.
Chapter 13, Unraveling a Mess, dives into how to go about safely modifying a legacy application that wasn't written with testing in mind. How can you add tests to minimize the potential for introducing new bugs when modifying the existing code? An extreme example will be used to explore these topics and more.
Chapter 14, A Better Foot Forward, emphasizes that TDD is a personal choice. You don't need anyone's permission to do good work. Advice on how to continue a successful journey of TDD, how to introduce TDD to your team, and how to rejoin the world as a TDD expert will be covered in this chapter.
