Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Pragmatic Test-Driven Development in C# and .NET

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

Arrow left icon
Product type Paperback
Published in Sep 2022
Publisher Packt
ISBN-13 9781803230191
Length 372 pages
Edition 1st Edition
Languages
Tools
Arrow right icon
Author (1):
Arrow left icon
Adam Tibi Adam Tibi
Author Profile Icon Adam Tibi
Adam Tibi
Arrow right icon
View More author details
Toc

Table of Contents (21) Chapters Close

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 18. Other Books You May Enjoy Appendix 1: Commonly Used Libraries with Unit Tests 1. Appendix 2: Advanced Mocking Scenarios

Answering frequently asked questions

Now that we have written the unit tests and the associated implementation, let me explain the process.

Are these unit tests enough?

The answer to this question depends on your target coverage and your confidence that all cases are covered. Sometimes, adding more unit tests increases the future maintenance overhead, so with experience, you would strike the right balance.

Why didn’t we unit test the controllers?

The controllers should not contain business logic. We pushed all the logic to the services, then tested the services. What is left in the controllers is minimal code concerned with mapping different types to each other. Have a look at the controllers in Uqs.AppointmentBooking.WebApi/Controllers to see what I mean.

Unit tests excel in testing business logic or areas where there are conditions and branching. The controllers in the coding style that we chose do not have that.

The controllers should be tested but through...

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image