Preface

As a consultant, I worked with many teams in multiple organizations. I’ve seen teams doing TDD and I’ve seen teams doing unit testing without TDD. I’ve also seen teams that thought they were doing unit testing but were doing integration testing and I’ve seen teams that are doing none! As an ordinary human being, I started forming a belief based on empirical evidence that TDD teams are the most successful, but this is not because they are using TDD! TDD results from having passion.

TDD is unit testing plus passion. Unit testing in some teams is imposed, therefore, the developers have to do it, but TDD is rarely imposed and it is up to the developers to enforce it on themselves. Needless to say, passionate developers produce quality projects and quality projects have more potential to succeed.

TDD is usually combined with some or all aspects of domain-driven design (DDD) architecture. So, I made sure I covered both TDD and DDD combined to be able to give realistic examples. I also wanted to reflect today’s market that is divided between two database categories, relational and document DBs, so I took the liberty to include an example chapter for each and show the differences in unit-testing implementations with the objective of keeping the book pragmatic.

Don’t be tricked by the book size, as the diagrams and the code snippets do inflate the book. I strived to stay away from old and impractical theories to shorten the book and stick to the point.

TDD and unit testing are in most modern job specifications, a requirement for interview test projects, and the subject of hot interview questions. If you wanted to know more about these topics and become a TDD developer, then you came to the right place.

There are many other good books on TDD and they are aimed at .NET developers as well, so why this book? In this book, I show real practical implementations by going to the DDD world, relational DBs, and document DBs. I demonstrate the decision tree of the mindset that practitioners use when doing TDD. I show the relationship between SOLID and TDD and I introduce a set of memorable best practices known as the FIRSTHAND guidelines of TDD.

My intention for writing this book is to have you as a confident TDD practitioner, or at least a unit-testing practitioner, and I hope I was able to deliver my intention.