You're reading from Pragmatic Test-Driven Development in C# and .NET Write loosely coupled, documented, and high-quality code with DDD using familiar tools and libraries

Product type Paperback

Published in Sep 2022

Publisher Packt

ISBN-13 9781803230191

Length 372 pages

Edition 1st Edition

Languages

Tools

.NET

Concepts

Test Driven Development

Author (1):

Adam Tibi

View More author details

Table of Contents (21) Chapters

Preface

1. Part 1: Getting Started and the Basics of TDD

2. Chapter 1: Writing Your First TDD Implementation FREE CHAPTER

3. Chapter 2: Understanding Dependency Injection by Example

4. Chapter 3: Getting Started with Unit Testing

5. Chapter 4: Real Unit Testing with Test Doubles

6. Chapter 5: Test-Driven Development Explained

7. Chapter 6: The FIRSTHAND Guidelines of TDD

8. Part 2: Building an Application with TDD

9. Chapter 7: A Pragmatic View of Domain-Driven Design

10. Chapter 8: Designing an Appointment Booking App

11. Chapter 9: Building an Appointment Booking App with Entity Framework and Relational DB

12. Chapter 10: Building an App with Repositories and Document DB

13. Part 3: Applying TDD to Your Projects

14. Chapter 11: Implementing Continuous Integration with GitHub Actions

15. Chapter 12: Dealing with Brownfield Projects

16. Chapter 13: The Intricacies of Rolling Out TDD

17. Index

Why subscribe?

18. Other Books You May Enjoy

Appendix 1: Commonly Used Libraries with Unit Tests

1. Appendix 2: Advanced Mocking Scenarios

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...