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

The First guideline

Unit tests should be written first. This might seem odd or unintuitive at the beginning, but there are valid reasons for this choice.

Later means never

How many times have you heard, we’ll test it later? I have never seen a team finishing a project and releasing it to production and then allocating time to unit test their code.

Moreover, adding unit tests at the end will require code refactoring, which might break the product, and it is hard to justify to a non-technical person that a working system was broken because the team was adding unit tests. Actually, the statement we broke production because we were adding unit tests sounds ironic. Yes, you can refactor a working system while covered by other types of tests, such as Sintegration and acceptance tests, but it would be difficult to imagine that a team that didn’t have time to unit test previously had the time to build other tests that would fully cover the system.

Testing first ensures...

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