I'll be honest, when I first looked at the title of this book, Practical Test-Driven Development Using C# 7, I thought "do we really need another book outlining the basics of unit testing and TDD?" I mean at this point, TDD isn't really that new, and plenty of authors have written about what TDD is and have given us countless examples of how to score a bowling or a tic-tac-toe game using TDD to drive the creation of the application.
The problems most developers run into when learning or trying to implement TDD is not understanding what TDD itself is and what "red, green, refactor" means, but how to practically implement it in real-world situations. Most real-world applications are messy and don't conform easily to the usual TDD shoehorn that many well-meaning TDD books and examples try to demonstrate. The real difficulty in successfully implementing TDD arises when you try to use it to develop a non-trivial application—an application with databases and multiple layers and external services you need to call.
As a consultant, I spent a large amount of time teaching teams who were supposedly doing TDD how to actually do TDD. I saw countless examples of teams who would hardcode tests with fake data or call out directly to a database, because they didn't really understand what a mock was and how to isolate their tests. Moreover, I found many development teams that understood the basics of TDD, but didn't understand how to take business requirements and user stories and convert them into working unit tests that they can actually use to develop the system they were trying to create.
I've never had a difficult time teaching software developers the basics of TDD. It's fairly easy to explain how TDD works and how to get started doing it—and there have always been plenty of resources available to teach all that. No, what companies paid me the big bucks for was to sit down with their teams and explain all the nuances of TDD. What do you do when you have to mock a class that directly uses the database? How do you handle 15 test cases that have different input values but are essentially testing the same thing? Where do we start with TDD—which tests do we write first?
That's where Practical Test-Driven Development comes into the picture. For the first time ever, all that "real tricky shit," that I thought only I knew about and was esoteric and complicated to explain in a book, well it's explained—with plenty of examples—right here in the one you are holding.
When I first cracked open Practical Test-Driven Development, I was amazed. Not only did it explain the right concept of what TDD was (a design activity, not a testing one), and give an absolute beginner a step-by-step approach to learning and understanding TDD, but it took it far, far from there and showed you how to practically and pragmatically apply the concepts to a real-world, non-trivial application and did it in a way that didn't try and gloss over the messy stuff. Instead, Practical Test-Driven Development plows right into all the nooks and crannies of TDD and tells you exactly the kinds of problem you will encounter and how to get past them.
Here's the best part—you don't even have to know a thing about TDD to get huge value out of this book and become a better TDD practitioner than 90% of software developers who claim they are already doing TDD. Practical Test-Driven Development is laid out in such a way that it assumes that you don't know anything about TDD and shows you step-by-step, example-by-example, everything you need to know to go from complete beginner to expert in a way that I honestly didn't think was possible, until I sat down and read the book myself.
All in all, I am extremely happy with this book and I have a feeling I'm going to be recommending it as the go-to resources for learning TDD for many years to come. Every developer should be doing TDD and doing it the right way. Therefore, every developer should read this book.
John Sonmez Founder, Simple Programmer