Amazon.com: Customer reviews: Unit Testing Principles, Practices, and Patterns: Effective testing styles, patterns, and reliable automation for unit testing, mocking, and integration testing with examples in C#
To calculate the overall star rating and percentage breakdown by star, we don’t use a simple average. Instead, our system considers things like how recent a review is and if the reviewer bought the item on Amazon. It also analyzes reviews to verify trustworthiness.
Bob is young and just started writing unit tests because he has heard it's such a great idea, he picked the "art of unit testing" book from bookshelf and he is ready to go, writes many tests, he is more than happy, finally, something checks his job, he is not afraid anymore to bug fix code because something is checking if he is not introducing any new bugs. Then, this day comes, Bob wants to rearrange his classes, methods and suddenly he is in a situation when he has to fix a million tests. Don't be like Bob, do a favor to yourself and buy this book.
Unit testing has been described as an art. While there is a lot of truth in that I have started to believe that it is also a science. Vladimir Khorikov takes a very methodical approach to the subject, one which I personally like a lot. His style is refreshingly confident and his recommendations are very clear (for example: treat time as an explicit dependency and injecting values not clocks). But he also backs his recommendations with logical reasons using alternative approaches as examples. There are a lot of tips related to good software design scattered throughout the book. I recommend it to anyone who writes software in a complex domain. Understanding what to test, how, and why will improve your code and your team's productivity.
Reviewed in the United States on September 9, 2020
awesome: * amazing breakdown of the two schools of thought with unit testing (haven't seen this articulated well before) * succinct definition for pillars of unit testing, in the past I've seen descriptors -- like in Growing Object-Oriented Software Guided by Tests -- but this is a good categorization of what makes a good unit test * tackles some very relevant approaches to building services and how it impacts your unit testing strategies, layered architecture, domain-driven design, functional programming * novel and good name of "observable behavior" as what you want to test
to improve: * the name of the pillar "resistance to refactoring" is not intuitive * while I personally agree with the pillar "resistance to refactoring" being very important, the argument and in-practice definition could be fleshed out quite a bit more. Part of the grey area, for me, is "observable behavior" not being defined better in practice. For example, I haven't been able to figure out when to stub vs when to verify for repository reads in my application services. It's not clear from the book or from its definition of "observable behavior", how to make your unit test resistant to refactoring.
I’ve been programming for a couple of years; I’ve written desktop and web applications but whenever I’ve try to write tests I’ve encounter with tons of example of very basic testing (sums, and prints). StackOverflow is full of that examples and what they cause (for me) was a repulsion, a dislike for unit-testing. Why would I test a basic property getter? It does not make any sense, etc. This book is the opposite. Is a guide for when to test what and why; but not how. I mean, it sure tells that but not with code-examples (internet is full of those ones). Instead the author guides you through a set of examples that really TEACHES you, because that (at leas for me) is the most important value of the book. It really TEACHES you, why to test, and what. I was very surprise because no matter English is not my first language, the book is clear and concise, and easy to read. It took me a couple of days. Excellent recommendation for anyone who has been doing software and now wants to test it.
I have always tried to write unit tests, but I never felt like I knew it well enough. I have researched the subject, tried to practice as much as I could. But it never felt like I was doing it properly.
Reading this book has made me understand testing at a much deeper level. Not simply the nuts and bolts of writing tests, but also appreciating how much the overall design of your code impacts the unit tests you write.
It has helped me identify why there are areas of my code that are difficult to test. And helped discover and fix unit tests that are fragile, not resistant to refactorings, or hard to maintain.
The book both demonstrate an excellent grasp of the testing concepts and provide a means of talking about them. Sharing a common understanding of the issues/problems with our unit testing practices is the first and probably most important step in improving and growing as developers.
The book covers test doubles in all their variants, what defines a good unit test, the different testing styles (and their strengths and weaknesses) and great insights into when (and when not) to use mock objects and test doubles.
I strongly recommend this book to any developer at any stage of their career.
There's a next level: not just writing tests, but doing it in a way that gives you the best return on your efforts. Unit Testing: Principles, Practices, and Patterns will guide you to that next level. As described in the Welcome, I did learn how to look unit testing in a new light, and see which tests contribute to the project and which must be refactored or eliminated. I found the text to be a perfect balance between theory and practice. Khorikov does an excellent job of defining the terms he uses. The chapter summary pages are dense with practical information. Refer back to the chapter text for lucid explanations of the details. As a result of reading this book I am changing my unit testing / TDD practice. Historically I have been London school, I am re-training myself to be more Classical. See the book for an explanation! As an added bonus in Chapter 10 you will get some context about database delivery practices. I will place the book in the "must read" recommendation along with Feathers, Seeman, Fowler, GOF, E. Evans, Uncle Bob.
Reviewed in the United States on September 10, 2020
This is one of the best book that you can get now on how to do unit/integration testing right. I bought it from Manning when it was still in progress and it really changed the way how I think about tests for the modern application. I can't recall any other book that describes that topic in a so coherent way and, at the same time, is applicable to the software written with DDD concepts in mind. You can get a good grasp of the TDD cycle from "TDD by Example" from Kent Beck, but it uses a very simple domain that you will not deal with in a real project. On the other hand, you can find a very good example of the real domain in "GOOS" by Steve Freeman and Nat Pryce, but that book focuses on a particular style of testing (the so-called London school or outside-in approach). Finally, there is a fascinated "London vs. Chicago" series by Robert Martin and Sandro Mancuso, but it doesn't give you a structured approach that books offer. This book combines all those things and gives you knowledge that otherwise will require a lot of years of exploring on your own. Author also has a great set of courses on DDD concepts on Pluralsight and great articles on his site. Thank you, Vlad.
Reviewed in the United States on September 14, 2020
I and our whole team have been struggling with unit testing for a long time. With all good intent, adding more tests didn't really help with maintaining the project. On the contrary, the tests we had written only impeded further development.
Before reading this book it felt like it's something everyone is talking about, but no one really knows how to do it right (maybe only those who invented it in the first place)...
Now I know that wasn't just a feeling. A whole unit testing school has emerged out of this lack of information on how to do it properly. This book covers difference in two approaches to unit testing, as well as what *good* unit tests are and how to write them.
Unfortunately, our team has not yet managed to rework poorly written tests we have, as we realized that it will require more time and effort than we expected. But at least we don't write bad unit tests anymore.
On the downside, this book doesn't cover UI testing much (if at all), but it is a book about unit testing after all...