What do you think?
Rate this book
Pragmatic Test-Driven Development in C# and .NET: Write loosely coupled, documented, and high-quality code with DDD using familiar tools and libraries
Build realistic applications with both relational and document databases and derive your code design using TDD. Unit test with xUnit and NSubstitute and learn concepts like DDD, SUT, Mocks, Fakes, Test Doubles, SOLID, and FIRSTHAND Test-driven development is a manifesto for incrementally adding features to a product but starting with the unit tests first. Today's project templates come with unit tests by default and implementing them has become an expectation. It's no surprise that TDD/unit tests feature in most job specifications and are important ingredients for most interviews and coding challenges. Adopting TDD will enforce good design practices and expedite your journey toward becoming a better coding architect. This book goes beyond the theoretical debates and focuses on familiarizing you with TDD in a real-world setting by using popular frameworks such as ASP.NET Core and Entity Framework. The book starts with the foundational elements before showing you how to use Visual Studio 2022 to build an appointment booking web application. To mimic real-life, you'll be using EF, SQL Server, and Cosmos, and utilize patterns including repository, service, and builder. This book will also familiarize you with domain-driven design (DDD) and other software best practices, including SOLID and FIRSTHAND. By the end of this TDD book, you'll have become confident enough to champion a TDD implementation. You'll also be equipped with a business and technical case for rolling out TDD or unit testing to present to your management and colleagues. This book is for mid to senior-level .NET developers looking to use the potential of TDD to develop high-quality software. Basic knowledge of OOP and C# programming concepts is assumed but no knowledge of TDD or unit testing is expected. The book provides in-depth coverage of all the concepts of TDD and unit testing, making it an excellent guide for developers who want to build a TDD-based application from scratch or planning to introduce unit testing into their organization.
372 pages, Paperback
Published September 30, 2022
10 people are currently reading
7 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 3 of 3 reviews
July 23, 2023
The author sets himself up for a failure right at the beginning of the book by claiming that TDD is usually combined with Domain-Driven Design (DDD), and he is going to cover both topics. TDD alone would fill a book and DDD is an even bigger topic. Unfortunately for the readers, we get from both parts a bit and from nothing enough to be useful.
The author loves abbreviations and acronyms, explaining them is not his strength. If you find yourself in front of an abbreviation that you have no clue about, keep reading. To get the definition of WFA you may need to read up to chapter 6, even when you start building it in chapter 3. The explanation for the prefix Uqs in the project names follows in chapter 7. Such things should be found by a copy-editor and get fixed before the book gets published.
The FAQ section for TDD is useless. Is there a difference between Agile Scrum and Scrum, Agile Kanban and Kanban or Agile XP and XP? Prefixing everything with Agile when you write about agile methodologies is pointless. The other answers are not better and will not tell you anything if you did not already have prior knowledge.
Sintegration tests is a term I never heard before. It has nothing to do with the company of the same name and after reading the book, it looks for me it is just a unit test for a bigger unit. Why the author needed a new name for what was known as outside-in-testing remains unknown.
One of the main problems of the book is that the author wants to cover too much in a chapter. The best example for that is the chapter on FIRSTHAND, where he writes about naming conventions, code coverage, extensions for Visual Studio, test frameworks, practices, offers a solution to freeze time and many, many more things. Other authors use FAST to define the important aspects of TDD tests and give the readers a chance to remember what the F stands for when they get to the T.
The DDD adventure starts in part 2. The explanation of DDD is shallow, uses the same example of a 5£ note everyone else does and fails to understand that the ubiquitous language is much more than the business language. The code examples end up with the usual mix of domain terms followed by a *Service or *Repository suffix and are full of primitive data types – as if the string and the int are the pinnacles of the ubiquitous language.
The applications that the author builds with DDD either have no tests (as in chapter 7) or the testing starts when there is already a lot of code around (chapter 8, 9 and 10). There would be challenging aspects in the user stories he picks, but the implementation with TDD always stops right before it gets interesting. Some of those challenges would show why it is a bad idea to use the discouraged Entity Framework In-Memory provider.
After many more repetitions that this book is only about testing the backend, we finally reach part 3. The chapter on GitHub Actions is not bad, even when it takes too much space in a book on TDD. The excursion into brownfield projects was the most useless part of the whole book. Nice diagrams show the questions you should ask, but if you look closer, you only get the consultants favourite answer of “it depends”. All that interweaved with the strawman argument that you cannot introduce unit testing because you have no safety net to make changes (then how do you keep changing the application to introduce new features?). The final chapter on the rollout of TDD had some good insights, but it came too late to save the book.
If you are interested in TDD, buy any other book on TDD.
The author loves abbreviations and acronyms, explaining them is not his strength. If you find yourself in front of an abbreviation that you have no clue about, keep reading. To get the definition of WFA you may need to read up to chapter 6, even when you start building it in chapter 3. The explanation for the prefix Uqs in the project names follows in chapter 7. Such things should be found by a copy-editor and get fixed before the book gets published.
The FAQ section for TDD is useless. Is there a difference between Agile Scrum and Scrum, Agile Kanban and Kanban or Agile XP and XP? Prefixing everything with Agile when you write about agile methodologies is pointless. The other answers are not better and will not tell you anything if you did not already have prior knowledge.
Sintegration tests is a term I never heard before. It has nothing to do with the company of the same name and after reading the book, it looks for me it is just a unit test for a bigger unit. Why the author needed a new name for what was known as outside-in-testing remains unknown.
One of the main problems of the book is that the author wants to cover too much in a chapter. The best example for that is the chapter on FIRSTHAND, where he writes about naming conventions, code coverage, extensions for Visual Studio, test frameworks, practices, offers a solution to freeze time and many, many more things. Other authors use FAST to define the important aspects of TDD tests and give the readers a chance to remember what the F stands for when they get to the T.
The DDD adventure starts in part 2. The explanation of DDD is shallow, uses the same example of a 5£ note everyone else does and fails to understand that the ubiquitous language is much more than the business language. The code examples end up with the usual mix of domain terms followed by a *Service or *Repository suffix and are full of primitive data types – as if the string and the int are the pinnacles of the ubiquitous language.
The applications that the author builds with DDD either have no tests (as in chapter 7) or the testing starts when there is already a lot of code around (chapter 8, 9 and 10). There would be challenging aspects in the user stories he picks, but the implementation with TDD always stops right before it gets interesting. Some of those challenges would show why it is a bad idea to use the discouraged Entity Framework In-Memory provider.
After many more repetitions that this book is only about testing the backend, we finally reach part 3. The chapter on GitHub Actions is not bad, even when it takes too much space in a book on TDD. The excursion into brownfield projects was the most useless part of the whole book. Nice diagrams show the questions you should ask, but if you look closer, you only get the consultants favourite answer of “it depends”. All that interweaved with the strawman argument that you cannot introduce unit testing because you have no safety net to make changes (then how do you keep changing the application to introduce new features?). The final chapter on the rollout of TDD had some good insights, but it came too late to save the book.
If you are interested in TDD, buy any other book on TDD.
May 17, 2023
Avoid this book if you are a beginner and are not well-read on concepts such as Domain Driven Design or unit testing. Had to pause reading to educate myself further but on returning I found it a well-referenced and enjoyable read.
February 13, 2023
If you you're a serious .Net developer and you work on a big project (or you want to) - you must have this book.
Displaying 1 - 3 of 3 reviews