What do you think?
Rate this book
Working Effectively with Unit Tests
Available at http://wewut.com
Unit Testing has moved from fringe to mainstream, which is great. Unfortunately, developers are creating mountains of unmaintainable tests as a side effect. I've been fighting the maintenance battle pretty aggressively for years, and this book captures the what I believe is the most effective way to test.
This book details my strong opinions on the best way to test, while acknowledging alternative styles and various contexts in which tests are written. Whether you prefer my style or not, this book will help you write better Unit and Functional Tests.
Unit Testing has moved from fringe to mainstream, which is great. Unfortunately, developers are creating mountains of unmaintainable tests as a side effect. I've been fighting the maintenance battle pretty aggressively for years, and this book captures the what I believe is the most effective way to test.
This book details my strong opinions on the best way to test, while acknowledging alternative styles and various contexts in which tests are written. Whether you prefer my style or not, this book will help you write better Unit and Functional Tests.
204 pages, ebook
First published June 29, 2014
About the author
Jay Fields
4 books22 followersJay Fields is a software developer at DRW Trading, conference speaker, and author. He has a passion for discovering and maturing innovative solutions. His most recent work has been in maturing software design through developer testing and software testing in general.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 25 of 25 reviews
July 4, 2014
It says "read", but that would be an exaggeration. "Briefly tolerated its existence before setting it on fire" would be more accurate. It burnt remarkably well, 5 stars.
July 25, 2014
I wish every developer I work with had read this book (including the past me). It distills into a surprisingly short amount of pages many important lessons that I've learned the hard way over a number of years. For a beginning or intermediate unit tester this book is a must-read. The most experienced unit testers may not find much new in it, but even they can benefit from seeing unit testing from the author's unique point of view.
What sets this book apart is its hands-on approach. You're thrown right into the deep end with a painfully realistic example. A bunch of tests have failed and it's your job to figure out what went wrong by reading the test output, the test code, and the code under test. This dreadful task gives you a very tangible impression of what it means for a test suite to be maintainable: the better the tests, the faster you'll be done.
In the rest of the book the author points out features of the test suite that make it hard to work with and demonstrates refactorings that alleviate the problems. There's nothing abstract about why each change makes the tests better. You can clearly see that with each new version the cause of failure becomes much easier to find. Sometimes this approach might lead to surprising solutions, for example, introducing duplication into DRY code, but you can't argue with results.
I found the book's objective approach to (test) code quality refreshing. As always in design, some decisions are simply a matter of taste, and the author makes it clear when what he's presenting is simply his preference.
This is one of my favorite books on testing, and if I could recommend only one, this would be it.
What sets this book apart is its hands-on approach. You're thrown right into the deep end with a painfully realistic example. A bunch of tests have failed and it's your job to figure out what went wrong by reading the test output, the test code, and the code under test. This dreadful task gives you a very tangible impression of what it means for a test suite to be maintainable: the better the tests, the faster you'll be done.
In the rest of the book the author points out features of the test suite that make it hard to work with and demonstrates refactorings that alleviate the problems. There's nothing abstract about why each change makes the tests better. You can clearly see that with each new version the cause of failure becomes much easier to find. Sometimes this approach might lead to surprising solutions, for example, introducing duplication into DRY code, but you can't argue with results.
I found the book's objective approach to (test) code quality refreshing. As always in design, some decisions are simply a matter of taste, and the author makes it clear when what he's presenting is simply his preference.
This is one of my favorite books on testing, and if I could recommend only one, this would be it.
December 29, 2014
A quick, enjoyable read. The focus of the book is how to improve ROI of your unit tests, and provides helpful suggestions to achieve this. There is no dogma here, nor anything revolutionary, but it's a solid addition to the testing literature.
If I have to list a downside, it's that all the examples are Java, and I wonder if some of the patterns are less valuable in other (say dynamic) languages. I would have loved to hear the author's thoughts on this, but it's a minor quibble, and I would still recommend this book to any engineer, no matter what languages they use.
If I have to list a downside, it's that all the examples are Java, and I wonder if some of the patterns are less valuable in other (say dynamic) languages. I would have loved to hear the author's thoughts on this, but it's a minor quibble, and I would still recommend this book to any engineer, no matter what languages they use.
July 11, 2014
This book is a breath of fresh air!
Things I really like:
* The evolution of a hairy test to something really clean is elegant.
* It skips the usual slow history and get straight to the point.
* I wish more people wrote tests like this. I see so many unit tests that make me sad due to over complicated abstractions that hamper readability. Having a book to point people at will really help.
* Doesn't get carried away with frameworks, DSLs and such, but mostly it's just really straight forward programming.
Thank you Mr Fields! I will be recommending this book to many people.
Things I really like:
* The evolution of a hairy test to something really clean is elegant.
* It skips the usual slow history and get straight to the point.
* I wish more people wrote tests like this. I see so many unit tests that make me sad due to over complicated abstractions that hamper readability. Having a book to point people at will really help.
* Doesn't get carried away with frameworks, DSLs and such, but mostly it's just really straight forward programming.
Thank you Mr Fields! I will be recommending this book to many people.
June 2, 2021
A beautiful book for those who are interested to learn more about unit testing in Java and Mockito. A bit of experience with these technologies is required.
The examples are super clear, although, the format of the code presented in the book is not the most reader-friendly, maybe it is something to be improved for future editions.
Some concepts like Solitary Unit Test, Sociable Unit Test, Unit Test ROI are clearly explained and offer a good overview about how unit tests should be written. Additionally, The author points out to some articles for those who are interested in getting a deeper understanding about these concepts.
Keen to start using some of these concepts in my code, however, a bit hesitant to follow recommendations like having "null" strings in the expected values (Some readers will probably agree with me after reading the book).
The author is clear about the fact that it is up to the reader to apply all the theories presented in this book, and that some of the recommendations might be the result of the author's personal preferences.
The examples are super clear, although, the format of the code presented in the book is not the most reader-friendly, maybe it is something to be improved for future editions.
Some concepts like Solitary Unit Test, Sociable Unit Test, Unit Test ROI are clearly explained and offer a good overview about how unit tests should be written. Additionally, The author points out to some articles for those who are interested in getting a deeper understanding about these concepts.
Keen to start using some of these concepts in my code, however, a bit hesitant to follow recommendations like having "null" strings in the expected values (Some readers will probably agree with me after reading the book).
The author is clear about the fact that it is up to the reader to apply all the theories presented in this book, and that some of the recommendations might be the result of the author's personal preferences.
May 29, 2021
It's really fun and easy to read, also gives you multiple strategies around "testing the hole picture" or just specific classes with some really practic and applied examples to avoid having a lot of brittle tests. Have you thought that there are multiple kind of unit tests? after this you will have a better picture of them.
In my experience I saw that people tends to not do unit test with the fear of spending more time updating/creating your test suit than in your features, but here, you will found that maybe is the way you are unit testing. The same argument applies to TDD but that's another topic.
I totally recomend it for those with or without experience.
In my experience I saw that people tends to not do unit test with the fear of spending more time updating/creating your test suit than in your features, but here, you will found that maybe is the way you are unit testing. The same argument applies to TDD but that's another topic.
I totally recomend it for those with or without experience.
July 25, 2014
This is a book I plan on strongly recommending to other developers. Jay Fields presents his strategy for testing and his definition of a unit test. The book starts with some marginal unit tests and slowly improves them. I found myself feeling uncomfortable with the initial version of the tests and it was rewarding seeing the tests improve and having that uncomfortable feeling disappear.
Why do you write tests? What do you try to get out of testing? How do you make failing tests useful? By the time you finish this book you should have a been driven to think about those questions and more. Even it you don't agree with Jay's approach this book will make you think.
You should read this book.
Why do you write tests? What do you try to get out of testing? How do you make failing tests useful? By the time you finish this book you should have a been driven to think about those questions and more. Even it you don't agree with Jay's approach this book will make you think.
You should read this book.
January 5, 2015
As someone who has done TDD for 10+ years, this book still taught me a few new things and made me reconsider how I like my tests setup. I really like the format of the book - by clearly addressing readers already experienced with testing Jay manages to keep the book short and information dense in a way I wish more technical writers would.
January 3, 2022
There is a lot of good stuff in here. My main gripe is that the author refers to blog posts in the book and simply states, this guy explains the x pattern well. Well that's great but I bought a paperback book with the intention of using it as a complete reference in the future. As time goes by these blog posts may disappear so this would be a more complete tome if the author did the extra work and summarized the information of these blog posts in his own book.
The paperback copy is quite affordable at $20 but unfortunately it is printed by amazon. This is the second technical book I've read that was published by amazon and like the previous it shows. The extra sheen, type setting, and font choices that a publisher would add to polish a book are missing. Welcome to the future where everyone can self publish but it looks half-ass.
I plan to use this book as a reference and apply some of the techniques described as time goes on so it is premature for me to give a proper review.
One thing that stuck out like a sore thumb for me was the following near the end of the book.
"I prefer to eliminate locals whenever possible. This preference is based on the conceptual overhead introduced by locals".
This is near the end of the book and Jay spends time eliminating locals. There is no proof that he provides that locals introduce conceptual overhead. Good grief, if you are a koder and can't deal with locals then you need a new profession. Just sayin'.
The paperback copy is quite affordable at $20 but unfortunately it is printed by amazon. This is the second technical book I've read that was published by amazon and like the previous it shows. The extra sheen, type setting, and font choices that a publisher would add to polish a book are missing. Welcome to the future where everyone can self publish but it looks half-ass.
I plan to use this book as a reference and apply some of the techniques described as time goes on so it is premature for me to give a proper review.
One thing that stuck out like a sore thumb for me was the following near the end of the book.
"I prefer to eliminate locals whenever possible. This preference is based on the conceptual overhead introduced by locals".
This is near the end of the book and Jay spends time eliminating locals. There is no proof that he provides that locals introduce conceptual overhead. Good grief, if you are a koder and can't deal with locals then you need a new profession. Just sayin'.
January 1, 2018
An opinionated masterpiece about how to write maintainable unit tests. This book contains lots of details and well thought-out practices. Highly recommended for those who want to step up their game when it comes to unit tests and TDD.
September 15, 2017
Good book. I think this book is best start point to know (unit) testing. If you are junior, you will find this book is very useful. Recommend it!
December 13, 2017
A very pragmatic discussion of the challenges writing unit tests, and the solutions that the author uses.
February 25, 2018
not a serious tdd book
the book go too fast over many deep contents, providing little insight. examples are really basic as well. waste of money.
the book go too fast over many deep contents, providing little insight. examples are really basic as well. waste of money.
December 20, 2019
Very Java-heavy, but lots of great advice that's applicable to testing in general.
January 20, 2015
Jay Fields uses in Working Effectively with Unit Tests a different approach than most authors that write about TDD: How does test-driven development creates value? As a measurement to judge the different approaches he uses ROI (return on investment) and explains the different side-effects certain styles of tests have. This (at least for me) new way to look at TDD is refreshing and helps to stay away from code bases that are impossible to change after an endless amount of tests are written that no longer justify the cost of maintaining them.
Be aware that the first examples he shows are only intermediary steps to a good solution. The first reaction after the initial refactoring may be “oh no!”. But those examples are only there to explain the problems and when you keep reading the code gets better and better. Maintaining a big code base with lots of tests is hard work. Applying a metric like ROI to challenge all tests and cutting them back on a regular basis is a good advice that will make your life simpler. When you do TDD you definitely should read this book. And when not this book may be give you a reason and a tactic to start writing more and better tests.
Be aware that the first examples he shows are only intermediary steps to a good solution. The first reaction after the initial refactoring may be “oh no!”. But those examples are only there to explain the problems and when you keep reading the code gets better and better. Maintaining a big code base with lots of tests is hard work. Applying a metric like ROI to challenge all tests and cutting them back on a regular basis is a good advice that will make your life simpler. When you do TDD you definitely should read this book. And when not this book may be give you a reason and a tactic to start writing more and better tests.
August 30, 2018
I didn't like the layout of the book. It made it hard to find the meat hidden in the book.
The main problem is that the book is probably 50% printed unit tests.
Personally, I find it unrewarding looking through code in a book.
I'd rather have seen carefully chosen snippets that illustrated the author's points.
The code could've been posted online and referred to allowing readers to utilizes IDE's to parse the code.
The author is also a bit dogmatic saying things should never/always (or at least almost always) be done his way. I am probably over-exaggerating this due to the authors inability to relate his points to solid examples. For example, the author is against using setup. I personally am at least ambivalent here. Separating state from assertions clarifies the intent of the test for me.
The main problem is that the book is probably 50% printed unit tests.
Personally, I find it unrewarding looking through code in a book.
I'd rather have seen carefully chosen snippets that illustrated the author's points.
The code could've been posted online and referred to allowing readers to utilizes IDE's to parse the code.
The author is also a bit dogmatic saying things should never/always (or at least almost always) be done his way. I am probably over-exaggerating this due to the authors inability to relate his points to solid examples. For example, the author is against using setup. I personally am at least ambivalent here. Separating state from assertions clarifies the intent of the test for me.
March 23, 2015
Great book, but my only quibble is that using Java for the examples requires much more code for writing tests than in a more dynamic language. I definitely learned a lot about designing unit tests, useful in any language.
February 12, 2015
The book is very pragmatic and short. Pretty nice overviews dos and don'ts of unit testing. With excellent examples to prove the points. But I would recommend to read "Growing object oriented software guided by tests" by N. Price first
May 22, 2016
Meh. It's good. It's probably directed to people that have been using unit tests for a very long time and use them extensively, which is not my case. It does have good info, it's probably that I don't know enough to get all of this book.
July 23, 2016
Great book. Jay did a great job of providing excellent examples and explanations behind why he is changing those tests. Another great thing about this book, that it's 330 pages but they are all about testing, and no history or other unrelated to testing material.
August 30, 2016
Amazingly crisp yet insightful.
January 18, 2018
Easy to read and informative.
April 11, 2017
I didn't like this book. Maybe because it didn't work well in the Kindle format. It was very difficult to follow the examples, due to layout problems.
April 16, 2017
Good book for people who has some experience with unit tests, but not too much (otherwise you'll find yourself constantly arguing with the author while reading).
Amount of code in the book is excessive and sometimes it's hard to follow what is it the important bit.
Amount of code in the book is excessive and sometimes it's hard to follow what is it the important bit.
April 24, 2017
If you are beginning with unit testing, then wait to read this book until you are comfortable with writing and executing unit testing for your code (including using test doubles / mocking). Once you are there or are close, read this book to improve your approach to unit testing in terms of what to test, how to test, how to structure tests, where to make trade-offs, what to trade. The book does not give you the exhaustive answers to these questions for all situations. It will provide answers to these questions that are applicable in most situations.
As with the maturity of fast-paced testing community, most of the observations in the book are opinions. As @JayJay Fields himself says "You won’t write better software by blindly following advice." So, consider the opinions/answers and use them as they best suit your needs.
While I agree with most of the observations/practices in the book, my only quip with the book was "do the examples overuse builders and mocks?" I often write unit tests that exercise external dependencies as this tells me when my code breaks due to a change in external dependencies. This may be the reason for my quip. That said, I haven't thought about how to convey the same information without builders/mocks.
In short, if you have just started to diligently write tests for your code, then read this book to write better tests :)
As with the maturity of fast-paced testing community, most of the observations in the book are opinions. As @JayJay Fields himself says "You won’t write better software by blindly following advice." So, consider the opinions/answers and use them as they best suit your needs.
While I agree with most of the observations/practices in the book, my only quip with the book was "do the examples overuse builders and mocks?" I often write unit tests that exercise external dependencies as this tells me when my code breaks due to a change in external dependencies. This may be the reason for my quip. That said, I haven't thought about how to convey the same information without builders/mocks.
In short, if you have just started to diligently write tests for your code, then read this book to write better tests :)
Displaying 1 - 25 of 25 reviews