What do you think?
Rate this book
Unit Testing: Principles, Practices, and Patterns
Unit Testing: Principles, Patterns and Practices shows you how to refine your existing unit tests by implementing modern best practices. You’ll learn to spot which tests are performing, which need refactoring, and which need to be deleted entirely! Upgrade your testing suite with new testing styles, good patterns, and reliable automated testing.
304 pages, Paperback
Published January 1, 2019
165 people are currently reading
1,315 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 - 30 of 102 reviews
May 30, 2020
This is one of the best book on unit testing I've read so far. It presents a good way to approach testing an enterprise application. It talks about how to analyze the quality of a unit test and how to write tests that have a good return on investment. The writing style is easy to follow and the author clearly arguments his point of view. I agree with almost all the advice in this book (and I've learnt some of these lessons the hard way). The book answers many of the popular questions related to unit testing and goes beyond trivial examples. It also delves into how to design your production code (since you can't have quality unit tests on poorly designed production code). Highly recommended, especially to read with your team, discuss, debate and agree on what a good test looks like.
January 26, 2020
This is great book on Unit Testing. I finally understood what a "Unit" is and more, how it is seen by the London and Chicago schools. It contains valuable advice on what makes a good unit test and how unit tests enable sustainable growth of a project. This is a must read for any developer. I liked it so much, that I started a book club with my colleagues where we go over the book in detail.
November 13, 2020
This book will be the most useful for those who write enterprise software using DDD with Hexagonal Architecture.
The title of this book is inaccurate. It is not only about unit testing but also about integration testing.
It describes differences, similarities, tradeoffs, and benefits of those two. That is why I think this book is so valuable. I still see developers who don't understand the difference and why unit testing is not enough.
Now instead of explaining, I will recommend your book :)
Great job, Vladimir!
The title of this book is inaccurate. It is not only about unit testing but also about integration testing.
It describes differences, similarities, tradeoffs, and benefits of those two. That is why I think this book is so valuable. I still see developers who don't understand the difference and why unit testing is not enough.
Now instead of explaining, I will recommend your book :)
Great job, Vladimir!
September 10, 2022
I bought it because I read the beginning of a free version, and I liked how it started. It has some good ideas mostly in the first third of the book.
It exposes familiar ideas in a different way and gives you more tools to explain and teach them.
But it has a lot of drawbacks, which is why I do not recommend it at all.
Some of them are:
Spam of his blog (throughout the book) and his course (at the end). Compared to other books I've read, this seems more like a self-promotional book than one that brings something new.
It's highly biased in some parts (and no, I'm not a London school enthusiast), especially in the use of mocks and how to deal with infrastructure code and decouple from it. If you disagree with his ideas about when to use mocks and why a third of the book is near to useless because it rests on these ideas.
It also talks about ports & adapters and functional architecture mixing facts with his beliefs, which could lead junior people to misunderstand these concepts.
I highly recommend to go for the source of these ideas reading , and .
And the most important book for new people . In this book when he talks about "refactor" he's saying "rewrite" and this is so dangerous without tests. In you will learn the difference and how to deal with it.
If you read all these books and want to learn new ways to explain the same concept, this book could help. But, if you are looking for a new source of concepts and well explained theory, in my opinion this is not your book.
It exposes familiar ideas in a different way and gives you more tools to explain and teach them.
But it has a lot of drawbacks, which is why I do not recommend it at all.
Some of them are:
Spam of his blog (throughout the book) and his course (at the end). Compared to other books I've read, this seems more like a self-promotional book than one that brings something new.
It's highly biased in some parts (and no, I'm not a London school enthusiast), especially in the use of mocks and how to deal with infrastructure code and decouple from it. If you disagree with his ideas about when to use mocks and why a third of the book is near to useless because it rests on these ideas.
It also talks about ports & adapters and functional architecture mixing facts with his beliefs, which could lead junior people to misunderstand these concepts.
I highly recommend to go for the source of these ideas reading , and .
And the most important book for new people . In this book when he talks about "refactor" he's saying "rewrite" and this is so dangerous without tests. In you will learn the difference and how to deal with it.
If you read all these books and want to learn new ways to explain the same concept, this book could help. But, if you are looking for a new source of concepts and well explained theory, in my opinion this is not your book.
March 22, 2020
I was waiting for this book. I've been following the author for a long time (pluralsight and blog) and I really like his approach to software enginnering. I'm definitely not dissapointed, it's a great book.
Pros:
- a lot of theory and side threads - that's what I like but if you prefer learning by practicing it might be an impediment - more text than code :)
- emphasising the role of the proper code design - it's not a book like "Let's write your first unit test...". I would even say that it's not just a book about unit testing per se. It's rather a pragmatic, holistic view on delivering maintainable software and how testing may ease it.
Cons:
- the book could have been longer :) I feel like few topics could have been extended, e.g. arrange part of tests or mocking (this part can easily grow fast when you use encapsulation and observable-behaviour style of testing. I thought that AutoFixture and it's capabilities will have been at least mentioned :))
Once again, it's a great position. I'm looking forward for a book about DDD!
Pros:
- a lot of theory and side threads - that's what I like but if you prefer learning by practicing it might be an impediment - more text than code :)
- emphasising the role of the proper code design - it's not a book like "Let's write your first unit test...". I would even say that it's not just a book about unit testing per se. It's rather a pragmatic, holistic view on delivering maintainable software and how testing may ease it.
Cons:
- the book could have been longer :) I feel like few topics could have been extended, e.g. arrange part of tests or mocking (this part can easily grow fast when you use encapsulation and observable-behaviour style of testing. I thought that AutoFixture and it's capabilities will have been at least mentioned :))
Once again, it's a great position. I'm looking forward for a book about DDD!
March 21, 2021
Since I have written my very first test suite, I had the voice in my mind saying "You can do better.".Because of that feeling, I was looking for answers about what exactly better means. The more I read, the more I asked the others about "What good test means and how to write a good unit test?" the more I was confused. I tried a lot of different approaches. Neither of them was ideal. Although I have found a good enough testing approach over time, I was looking for the answers continuously. And finally, I found that book. I wish I had read it a few years ago. It would make my learning curve way smoother. The book systematized my knowledge and taught me a lot from code examples. Now I'm sure, and I can answer how to write better tests. Thank you!
Of course, the book is not a silver bullet. What I missed is the integration tests using pure SQL or micro ORM. Also, the application layer could show examples of IO sandwich with more than three layers. After the reading, I feel that I don't know which approach is the best. Should I test each layer separately or not?
Even though I may argue with the author about few minor aspects, it is definitely one of the must-reads.
Of course, the book is not a silver bullet. What I missed is the integration tests using pure SQL or micro ORM. Also, the application layer could show examples of IO sandwich with more than three layers. After the reading, I feel that I don't know which approach is the best. Should I test each layer separately or not?
Even though I may argue with the author about few minor aspects, it is definitely one of the must-reads.
July 11, 2020
Great book once you've gotten down the basics & have some experience with unit testing but feel something is off. Puts forward a framework on what makes a "good test" and discusses the relationship between testing strategy and design (hexagonal architecture, functional core/imperative shell).
Provides useful heuristics on "when to test", "when to mock dependencies vs when to use a real dependency in tests", etc.
I don't fully agree on all of the proposed heuristics, but it's a refreshing read that provides a concrete and opinionated approach, dives deeper than the basics & puts testing and testability in perspective of broader concerns like maintainability, architecture & design. Recommend!
Provides useful heuristics on "when to test", "when to mock dependencies vs when to use a real dependency in tests", etc.
I don't fully agree on all of the proposed heuristics, but it's a refreshing read that provides a concrete and opinionated approach, dives deeper than the basics & puts testing and testability in perspective of broader concerns like maintainability, architecture & design. Recommend!
September 14, 2020
I had been writing unit tests for a pretty long time, I had even read and followed the practices in books about unit testing, but most of the unit tests I had created were mediocre until I read this one. This is the best book about unit testing I've ever read. It gave me good and practical guidelines for unit testing. The content and the concepts were written and explained in a very intuitive and easy to understand style, even for a guy who doesn't speak English as a native language like me.
I introduced this book to my development team, and we've been practicing the guidelines from it in our daily work since then. This book is worth your time reading.
I introduced this book to my development team, and we've been practicing the guidelines from it in our daily work since then. This book is worth your time reading.
October 30, 2022
The book concentrates mostly on unit and integration tests, but also covers some of end-to-end category.
Although author shares important theoretical foundations around software testing, the book is written mostly from practical viewpoint, based on the authors personal experience.
First few chapters will help you a lot to understand the key parameters that define the quality of tests in general, and as author notes, he intends to show you the frame of reference that you can use to analyze any test in your test suite.
Overall, from my perspective a must read book for both developers and QA engineeers.
Although author shares important theoretical foundations around software testing, the book is written mostly from practical viewpoint, based on the authors personal experience.
First few chapters will help you a lot to understand the key parameters that define the quality of tests in general, and as author notes, he intends to show you the frame of reference that you can use to analyze any test in your test suite.
Overall, from my perspective a must read book for both developers and QA engineeers.
May 4, 2021
It covers more just only unit testing, but also integration testing and some architecture/design concerns like Hexagonal architecture or funcional programming and logging. Author of the book belongs to Detroit (Classic) camp of unit testing, and I belong to London. So it was reading a book about how "enemy" thinks. There are good insights but didn't attract to their camp. As usual examples in book are pretty simple to demonstrate good sides of classic approach and DDD. But when it takes big Enterprise applications (the ones I work with) it doesn't seem so simple anymore.
January 26, 2020
Every learning material prepared by Vladimir Khorikov is excellent ( video courses, blog posts). This book, of course, is not an exception to this rule! This book contains very valuable knowledge and I recommend it to every software developer, no matter which programming language one uses. I wish I could have read it a few years ago.
August 26, 2020
Best book on programming I've read in a while (although admittedly that's not saying much, as I've barely read anything on programming since mid 2018). I've always been an ardent proponent of a version of test driven development: don't develop anything in your program unless its behavior can be pinned down through tests. That means that if you change any part of the code and the tests break, you know immediately if you screwed up, or if anything about the architecture of the code legitimately needs to change. If you are a good programmer, your architecture will change at least in minor ways every day: if you find yourself doing stuff twice, you should refactor both parts into a single abstraction (even if the level of abstraction is just a function) that gathers the similarities. Programming is a constant attrition war against entropy, and if you aren't sure that you can change any part of the program without ruining any behavior somewhere else, you will find yourself making excuses to leave that problematic part alone. Going that route you'll end up with a program in which you cannot change anything because any other part will break in unpredictable ways, and you cannot fix the bugs that now proliferate.
The author articulates something I had felt but hadn't articulated to the extent the author has: you need to focus on testing behaviors related to the business needs of the domain you are programming. For example, if you are programming some pathfinding algorithm, set one or more tests that cover the exact path that the agent will produce (because they are deterministic). It doesn't matter how many functions, classes or whatever it takes to pass that test. That differs enormously from early, late 2000s test driven design proponents, that argued that even constructors and getters ought to be tested (as in literally you shouldn't write any function that doesn't pass a test). Going that absurd old route you get people who use coverage tools not as a guide to know which parts of your codebase require further testing, but as an obligation to reach 100% coverage. In reality, some parts of your code such as dumb controllers, constructors or getters do not need to be tested. In addition, every line of code you add to your program has a cost and requires maintenance. That includes tests, as they need to be compiled. Don't add shit to your codebase that doesn't contribute enough.
The author also argues about the necessity to write tests from the perspective of the client of whatever part of the code you are testing: the tests should just pass parameters and assert whether the tested part produces an expected result. Do not use mocks to test how internal functions or components talk to each other, only use mocks to isolate visible side effects, such as calls to databases, file systems, online services, etc, as well as to stub out problematic dependencies. However, regarding problematic, possibly volatile, non-deterministic dependencies, you'd better wrap them into a trait/interface and just pass that into other structures as either parameters or through dependency injection.
The author articulates something I had felt but hadn't articulated to the extent the author has: you need to focus on testing behaviors related to the business needs of the domain you are programming. For example, if you are programming some pathfinding algorithm, set one or more tests that cover the exact path that the agent will produce (because they are deterministic). It doesn't matter how many functions, classes or whatever it takes to pass that test. That differs enormously from early, late 2000s test driven design proponents, that argued that even constructors and getters ought to be tested (as in literally you shouldn't write any function that doesn't pass a test). Going that absurd old route you get people who use coverage tools not as a guide to know which parts of your codebase require further testing, but as an obligation to reach 100% coverage. In reality, some parts of your code such as dumb controllers, constructors or getters do not need to be tested. In addition, every line of code you add to your program has a cost and requires maintenance. That includes tests, as they need to be compiled. Don't add shit to your codebase that doesn't contribute enough.
The author also argues about the necessity to write tests from the perspective of the client of whatever part of the code you are testing: the tests should just pass parameters and assert whether the tested part produces an expected result. Do not use mocks to test how internal functions or components talk to each other, only use mocks to isolate visible side effects, such as calls to databases, file systems, online services, etc, as well as to stub out problematic dependencies. However, regarding problematic, possibly volatile, non-deterministic dependencies, you'd better wrap them into a trait/interface and just pass that into other structures as either parameters or through dependency injection.
September 19, 2020
This book is a must read for anyone serious about unit testing. If you're not serious about unit testing then consider another job!
So many times, in my career, I’ve encountered tests suits that are hard to maintain, grapple with, turn red and go back to green for no explicit reason. I’ve seen developers comment out large bunch of tests because they can’t fix them but are eager to build and release. These test suites gradually degrade and has the look and feel of a vandalized area.
Personally, I’m always bothered about creating a poor test suite and agonizing over difference approaches. This book instills a mindset and provides what approach to take and when. Vladimir is lawyer-esque in taking a problem, breaking it down to it parts, analyzing them and putting it all back together with clear conclusions. The beauty of what Vladimir does it to take a difficult topic and make it explainable to any level of developer. Following the practices in this book will not only improve your tests but will also improve the way you think about coding a solution or refactor it.
So many times, in my career, I’ve encountered tests suits that are hard to maintain, grapple with, turn red and go back to green for no explicit reason. I’ve seen developers comment out large bunch of tests because they can’t fix them but are eager to build and release. These test suites gradually degrade and has the look and feel of a vandalized area.
Personally, I’m always bothered about creating a poor test suite and agonizing over difference approaches. This book instills a mindset and provides what approach to take and when. Vladimir is lawyer-esque in taking a problem, breaking it down to it parts, analyzing them and putting it all back together with clear conclusions. The beauty of what Vladimir does it to take a difficult topic and make it explainable to any level of developer. Following the practices in this book will not only improve your tests but will also improve the way you think about coding a solution or refactor it.
October 11, 2022
The entire book is based on the idea of you having a project based on a DDD approach. If you don't, the book is useless.
Another thing I don't like is that you can sense on every page of the book that the author does not like London school (TDD) at all, and there are even a few entire pages in which he brings his arguments about why this type of testing is wrong. If you like mocks, or if you are expecting a book about testing/unit tests/integration tests/etc independent of your architecture, you'll be very disappointed.
Compared to other books, this one had too many examples that could be found on different URLs. It almost felt like it was material written to get more followers for some Pluralsight courses or blogs.
All in all the book, it's ok to find out another opinion on how you can write your tests, but I wouldn't recommend it, as a "first to read" book, on this subject. If you don't have good knowledge of the subject before reading it, you will do a complete mess of your project if you just start implementing stuff from this book.
Another thing I don't like is that you can sense on every page of the book that the author does not like London school (TDD) at all, and there are even a few entire pages in which he brings his arguments about why this type of testing is wrong. If you like mocks, or if you are expecting a book about testing/unit tests/integration tests/etc independent of your architecture, you'll be very disappointed.
Compared to other books, this one had too many examples that could be found on different URLs. It almost felt like it was material written to get more followers for some Pluralsight courses or blogs.
All in all the book, it's ok to find out another opinion on how you can write your tests, but I wouldn't recommend it, as a "first to read" book, on this subject. If you don't have good knowledge of the subject before reading it, you will do a complete mess of your project if you just start implementing stuff from this book.
April 3, 2020
First the disclaimer, this book is not for those who are completely new to tdd.
I would highly recommend Kent Becks book and growing oo software using tests. However if you have a little tdd experience then this book is real gold mine. Some real deep knowledge is shared by the author with good practical code samples.
I really this book is a classic on a par with clean code, refactoring, pragmatic programmer and the like.
I would highly recommend Kent Becks book and growing oo software using tests. However if you have a little tdd experience then this book is real gold mine. Some real deep knowledge is shared by the author with good practical code samples.
I really this book is a classic on a par with clean code, refactoring, pragmatic programmer and the like.
August 16, 2023
The book should be called acceptance testing in DDD not Unit testing. Since testing as he describes it requires certain architectural layers (application, infra, domain). And it is only applicable to core sub domains with rich domain model. So it has nothing to do with Unit testing and author is trying to sell you DDD more than Unit testing.
September 14, 2020
The book is excellent and goes right to the point of making good unit testing.
This book is the best I have read about this topic.
Thanks Vladimir
This book is the best I have read about this topic.
Thanks Vladimir
July 9, 2020
This book is a great primer to unit testing and offers numerous heuristics in evaluating their value, maintenance requirements, as well as the code being tested.
I really enjoyed it and finished it within a week, which speaks to the conciseness of the book. Vladimir explains fairly abstract ideas clearly and simply, aided by various diagrams and code samples. Rarely did I have to look things up despite no C# experience. The code examples are great as Vladimir often teaches by iterating and improving upon it. In addition to unit testing, I've also learned so much about writing good code in general.
One of the things I really appreciated was how well he knows his readers. There were many times while reading I would be asking "but why not this way instead?," and he'll immediately follow it with the explanation as if reading my mind. I also really appreciated how opinionated he was, but always explaining why. The main example being his thorough analysis of Classical versus London schools of unit testing and why he advocates the former.
Some may be off put by the academia-like theories Vladimir proposes, especially in the earlier chapters. While computer science is rooted in rigorous math and proofs, most programmers are probably more tinkerers and enjoy the "practical" side of writing software. Still, I think it's important to formalize ideas and create a common frameworks for thought that allow us to easily communicate, which the author does well.
I only have a few minor suggestions for improvement. I would have to liked to see how this fits into the overall development process. Also, I wish there was an example that showed the tests in their entirety along with the folder structure.
I really enjoyed it and finished it within a week, which speaks to the conciseness of the book. Vladimir explains fairly abstract ideas clearly and simply, aided by various diagrams and code samples. Rarely did I have to look things up despite no C# experience. The code examples are great as Vladimir often teaches by iterating and improving upon it. In addition to unit testing, I've also learned so much about writing good code in general.
One of the things I really appreciated was how well he knows his readers. There were many times while reading I would be asking "but why not this way instead?," and he'll immediately follow it with the explanation as if reading my mind. I also really appreciated how opinionated he was, but always explaining why. The main example being his thorough analysis of Classical versus London schools of unit testing and why he advocates the former.
Some may be off put by the academia-like theories Vladimir proposes, especially in the earlier chapters. While computer science is rooted in rigorous math and proofs, most programmers are probably more tinkerers and enjoy the "practical" side of writing software. Still, I think it's important to formalize ideas and create a common frameworks for thought that allow us to easily communicate, which the author does well.
I only have a few minor suggestions for improvement. I would have to liked to see how this fits into the overall development process. Also, I wish there was an example that showed the tests in their entirety along with the folder structure.
September 18, 2020
I think that this is a truly inspiring book for developers who want to have a simple maintainable code.
I was used to mock all the classes from the business logic and do unit tests for verifying interaction between business logic classes and these actions caused issues in maintaining the tests. I know understand that our code focused too much on implementation details than on observable functional behavior.
This book opened my mind towards a domain driven design perspective, clean architecture, a logical and simple approach for testing.
The writing style also helped me to understand quickly the notions as it is concise, covers mostly all the code areas that can be tested and provides good motivation on what is valuable to test or not. Also, the writing style is close to how a developer thinks by providing clear code examples and clear motivation on when to use coding or testing techniques.
The author is eager to respond to questions and keeps collaboration with the readers. I sense that the author cares upon adding a contribution to the worldwide code quality.
This book started the road for me for learning and I am really grateful that it exists.
I was used to mock all the classes from the business logic and do unit tests for verifying interaction between business logic classes and these actions caused issues in maintaining the tests. I know understand that our code focused too much on implementation details than on observable functional behavior.
This book opened my mind towards a domain driven design perspective, clean architecture, a logical and simple approach for testing.
The writing style also helped me to understand quickly the notions as it is concise, covers mostly all the code areas that can be tested and provides good motivation on what is valuable to test or not. Also, the writing style is close to how a developer thinks by providing clear code examples and clear motivation on when to use coding or testing techniques.
The author is eager to respond to questions and keeps collaboration with the readers. I sense that the author cares upon adding a contribution to the worldwide code quality.
This book started the road for me for learning and I am really grateful that it exists.
February 27, 2025
There are relatively few books on unit testing and software testing in general, and even fewer that systematically compare and contrast the different schools of thought in this domain. The initial chapters of this book excel in providing such a comparison.
Subsequently, the book effectively introduces the classical school of unit testing, supporting its advocacy with well-structured examples. While certain arguments presented by the author were not entirely convincing, and some logical connections appeared to be missing, the overall flow of the book, the clarity of explanations, and the selection of topics contributed to an engaging and informative reading experience.
I highly recommend this book, along with Growing Object-Oriented Software, Guided by Tests, to all software engineers, as both are essential reads in the field.
Subsequently, the book effectively introduces the classical school of unit testing, supporting its advocacy with well-structured examples. While certain arguments presented by the author were not entirely convincing, and some logical connections appeared to be missing, the overall flow of the book, the clarity of explanations, and the selection of topics contributed to an engaging and informative reading experience.
I highly recommend this book, along with Growing Object-Oriented Software, Guided by Tests, to all software engineers, as both are essential reads in the field.
March 10, 2020
I thoroughly enjoyed the writing style from in this book. It was a joy to read, and I never felt like I was reading a dry technical book. The content was presented in an engaging manner with relevant and easily understandable examples.
I never thought testing was such a complicated topic, and always wondered why I never trusted the tests I wrote. This book explains the theory of testing and allowed me to identify previous errors I had made when writing tests. I was rewriting tests for a project that I have been working on as I read this book and I now have much more confidence that the source code is correct and the tests are helpful.
I also found the explanation of how design patterns are linked to tests helpful and thought-provoking. There are many great examples of how design patterns can be used to make source code and tests more reliable. I have seen many of these ideas but the examples from this book were more helpful and convincing.
Overall, this book had a tangible impact on how I build software. It made me think about software at a new level, and challenged me to change some of my habits. That's a pretty great return on any book.
I never thought testing was such a complicated topic, and always wondered why I never trusted the tests I wrote. This book explains the theory of testing and allowed me to identify previous errors I had made when writing tests. I was rewriting tests for a project that I have been working on as I read this book and I now have much more confidence that the source code is correct and the tests are helpful.
I also found the explanation of how design patterns are linked to tests helpful and thought-provoking. There are many great examples of how design patterns can be used to make source code and tests more reliable. I have seen many of these ideas but the examples from this book were more helpful and convincing.
Overall, this book had a tangible impact on how I build software. It made me think about software at a new level, and challenged me to change some of my habits. That's a pretty great return on any book.
September 14, 2020
For me, this is hands down the best material out about unit testing.
I have been learning related practices for years, but always had the feeling that I missed something and the "mock everything" way of unit testing is not the most suitable practice to work with.
In the projects I participated, my colleagues continuously increased the amount of less valuable unit tests (if the design allowed that at all) and the fragility brought by the mockish thinking quickly became a burden that defeated the concept.
I wish this book came out much more earlier, so that I could skip the others, going through only the basics, over and over again, teaching unit testing the wrong way.
I have been learning related practices for years, but always had the feeling that I missed something and the "mock everything" way of unit testing is not the most suitable practice to work with.
In the projects I participated, my colleagues continuously increased the amount of less valuable unit tests (if the design allowed that at all) and the fragility brought by the mockish thinking quickly became a burden that defeated the concept.
I wish this book came out much more earlier, so that I could skip the others, going through only the basics, over and over again, teaching unit testing the wrong way.
September 23, 2020
Unexpected
Cause i already know, practice and value much of what this book is trying to teach,
I wasn't really expecting to enjoy this book as much as I did,
it is packed full of really useful information,
it is easy to read, and engaging enough to read cover-to-cover.
This is the kind of book on Unit Testing i would have liked to have had when I started my career as a Software Engineer.
Cause i already know, practice and value much of what this book is trying to teach,
I wasn't really expecting to enjoy this book as much as I did,
it is packed full of really useful information,
it is easy to read, and engaging enough to read cover-to-cover.
This is the kind of book on Unit Testing i would have liked to have had when I started my career as a Software Engineer.
March 8, 2021
I bought this book after finding the authors online courses excellent and have been writing unit tests of varying merit for several years.
I found the book extremely easy to read, especially for essentially a text book. I was actually gripped and read the whole book in 48 hours.
The concepts in the book come with very good, clear examples and was easy to follow. The structure makes sense and each section comes with a useful summary for referring back to when done.
If you want to understand more about effective unit testing or like me just feel like your unit tests are a bit dubious at times this is an essential resource.
I found the book extremely easy to read, especially for essentially a text book. I was actually gripped and read the whole book in 48 hours.
The concepts in the book come with very good, clear examples and was easy to follow. The structure makes sense and each section comes with a useful summary for referring back to when done.
If you want to understand more about effective unit testing or like me just feel like your unit tests are a bit dubious at times this is an essential resource.
June 20, 2020
Hight quality book discussing many practical parents for application testing. Author insights are priceless - you can definitely say that they come from wide experience. Book presents a high-level picture of the application testing and many patterns that will improve quality of your tests.
Examples are in C#, but they are quite simple, so any programmer even with basic knowledge of programming language will easily understand them.
This is the best book I read about testing. Highly recommended.
Examples are in C#, but they are quite simple, so any programmer even with basic knowledge of programming language will easily understand them.
This is the best book I read about testing. Highly recommended.
September 10, 2020
This is a must read for every developer. Vladimir covers a lot in this book that contains eye-opening valuable knowledge that will improve your overall skills around TDD.
I have been passionate about TDD and I always find a challenge to make the test suite maintainable especially when it will be supported by different teams. This book gave me myriads of tips and techniques on how to keep our test suite manageable and highly maintainable.
I highly recommend this book for all levels.
I have been passionate about TDD and I always find a challenge to make the test suite maintainable especially when it will be supported by different teams. This book gave me myriads of tips and techniques on how to keep our test suite manageable and highly maintainable.
I highly recommend this book for all levels.
July 7, 2020
Best book which I have read on automated testing for a while.
As an experienced developer practicing unit testing for years this book taught me a lot of new things. Definitely not a book for beginner.
Highly recommended.
As an experienced developer practicing unit testing for years this book taught me a lot of new things. Definitely not a book for beginner.
Highly recommended.
September 13, 2020
This book is amazing. Especially for the folks who already into unit testing and have faced difficulties by their own example. With a high degree of probability, they will find answers to many of their questions in this book.
September 20, 2020
I recommend this book to everyone. I finally understood the concepts of testing behavior (instead of implementation details), mocking, and integration testing. I even introduced my team to integration testing with great effect.
February 16, 2021
One of the best books that I have read about software development, and by far about unit testing. It changed my perspective on unit testing, but also on how to produce code of good quality. I also got a firmer understanding about DDD, esp. with regards to unit testing. The author writing is concise and right to the point, and every chapter was interesting and filled with little nuggets of knowledge. I would also recommend his blog , that has a lot of great blog posts about software development.
Displaying 1 - 30 of 102 reviews
Can't find what you're looking for?
Get help and learn more about the design.