About the Author
Tomek Kaczanowski is a technical team leader from Krakow, Poland. He has a strong interest in code quality, testing and automation - preferably all three together. Combining technical with soft skills, he also ventures into the realms of mentoring, teaching, lecturing and article writing, not to mention preaching sermons to the unconverted in the hope of redeeming them (or at least their code)! He hates doing things manually, and is allergic to empty src/test/java directories.
Tomek believes that by working with legacy code, and improving it, he can make the world a better place. To his disappointment, the world does not seem to care all that much about his efforts.
Apart from all this weirdness, he is a pretty normal person – a husband, father of two, and cat owner.
vii
Acknowledgments
In various different ways a number of people have helped me with writing this book – some by giving feedback, others by comforting me in times of doubt.
Marcin Stachniuk was the first person to offer to review the book in the early stages of its being written, and at the same time the most persistent of my reviewers. He read every part of the book and gallantly overcame the obstacles I frequently put in his way: frequent releases, constant juggling of the contents, minor piecemeal adjustments, etc.
Piotr Przybylak helped a lot by introducing me to the concept of "personas".
Michal Margiel read the whole book and sent me a long list of defects he had identified. Some of his remarks regarding code style were very pertinent, and after I had introduced them the book seemed far better than before!
Pawel Lipinski, Marcin Zajaczkowski, Pawel Wesolowski, Rafal Janik, Daniel Longosz and Krzysztof Jelski also contributed by verifying several sections of the book.
Szczepan Faber, Mockito’s author, has given me a good bashing, unearthing several weaknesses in the book as it went along, but at the same time has appreciated my work and encouraged me to go on with it. Jakub Naruszewicz and Shamil Daghestani helped preparing Kindle version of the book.
I have also received a great deal of encouragement from Java community members on social networks. Thanks to all of you!
This book would never have happened if it had not been for the (unwitting) help of thousands of bloggers and mailing group debaters. I have learned a lot from, and have been inspired by, numerous Java, PHP, Ruby and .Net articles, blog posts and discussions. It is amazing to find out that despite the differences in tools and approaches, so many of us share the same ideals of clean, perfect code, and that we also rack our brains about similar issues.
I have also learned a considerable amount from the participants in training sessions that I myself have conducted. By sharing their doubts and comments with me, they have helped me to rethink my stances and look for even better solutions, approaches or tools.
My colleagues at work have given me much food for thought, just by doing things differently from how I would, while insisting that their way is better! :) This has also helped me go forwards, even if I’ve sometimes had to take a few steps backwards first!
Carl Humphries has done a splendid job by translating this book from my version of English into a standard one. You would not enjoy reading this book at all, were it not for his hard work!
My gratitude also goes out to the authors, contributors and community members of all of the numerous fantastic free tools, libraries and applications I have made use of while writing it. My deepest respect goes to everyone who contributed even a single line of code to the following projects: AsciiDoc, Docbook, vim, Apache FOP, xlstproc, Subversion, IntelliJ IDEA, FoxitReader, Calibre, EPUB Reader, Inkscape, Gimp, ImageMagick, LibreOffice, PCLinux OS, various bash tools (grep, diff, tree, etc.), xmind.net, toodledo.com, clker.com, wikipedia.org, stackoverflow.com, xp-dev.com and github.com. I would also like to thank all the people on the AsciiDoc and Docbook mailing lists for bearing with me, even when my questions seemed foolish.
Even though many people have contributed to this book and have carried out reviews, all bugs still belong to me!
viii
Acknowledgments
My family has also made an immense contribution. Agnieszka, my wife, has supported my work from the very beginning, repeatedly reminding me about the need to focus on getting things finished, and giving up some of her so-called "free-time" so that I could have more time to spend on it. Without her help, I would simply have never finished the book!
My daughters - Zosia and Helenka - gave me reasons to smile every day; something I needed very much, being tired and depressed with the amount of work still lying before me.
Our cat - Boni - has played a double game. Some evenings she helped me to calm down by sitting on my lap, purring softly, while sometimes she deprived me of sleep by making an awful racket at night! :)
ix
Preface
Times are bad. Children no longer obey their parents, and everyone is writing a book.
— Cicero
Why Another Testing Book?
There are already a few really good books devoted to developers’ tests in bookstores, so why write another one? Here are several reasons for doing so:
The world keeps on moving forward. Progress never stops. There are still ideas emerging in the testing area. New frameworks. New approaches. New tools. Old techniques are being forgotten, rediscovered and mixed with newly invented ones. New concepts force us to rethink existing paradigms and come up with solutions that are better suited to the constantly changing IT environment.
Lack of knowledge. In spite of all the books, seminars, JUG meetings, conferences, podcasts, articles, blog entries and forum discussions I deal with, I still meet many developers who have only a very vague idea of what developers’ testing is and how to do it. There is definitely still room for improvement in this area.
People are different. Despite the number of available sources on the subject of testing, some developers still seem oblivious to its importance and to the techniques it involves. Maybe the approach taken in this book will help them (you?) to absorb this knowledge and acquire some testing skills.
Last but not least, let me say that writing a book feels like the natural next step for me. After hours spent honing my testing skills, blogging about this and sharing my knowledge at JUG meetings and conferences, I feel it is time to make this step. I hope you enjoy the results.
Who Is This Book For?
This book is aimed at developers who want to produce high-quality, maintainable unit tests. It is intended especially for those who would like to start unit testing their code, but are unsure about how to get started and what to focus on.
If you are already an experienced developer with some skills in testing, then you might gain various things from reading it. You can expect a good recap of unit testing issues and best practices, along with code examples which might remind you about some rules and best practices you have forgotten. I am also sure that you will find a lot of new things here – some, even, which will make you rethink your current practices.
What I Expect From You
In fact there is very little I expect from you, except that you are willing to learn, and ready not just to rethink your current ways of writing code but also to rethink (and maybe even reject!) things you learn from this book. Stay sharp! Question what you know and what you learn! Authors of books are sometimes wrong too!
Apart from having this attitude, you need to know at least the basics of Java (equivalent, let’s say, to a Junior Java Developer).
x
Preface
How To Read This Book
Successive chapters make use of the information given in their predecessors, so it would make sense to read it chapter by chapter. This is certainly true for Part I, "Developers’ Tests", and Part II, "Writing Unit Tests". The first introduces developers’ tests in general terms and provides some theoretical information about unit tests, and the second gives practical advice about the creation of unit tests. However, Parts III, IV and V, which go more deeply into the realm of unit tests and contain various topics, can largely be read in isolation from the previous parts.
…and if you really cannot wait to see some code (impatient, aren’t we?), go straight to Chapter 3, Unit Tests with no Collaborators in the second part of the book. I hope that at some point you will also read Part I, as this may prove necessary for understanding Part II as a whole.
There are also four appendices. If you are new to the idea of automated tests, then you should definitely read the first of these: "Automated Tests". It explains their advantages over manual testing, and provides information about the organizing of the execution of tests. The second appendix, "Running Tests", shows how to use an IDE and build tools to execute unit tests and debug them. The third, "Test Spy vs. Mock", discusses the differences between these two types of test double in detail. The last one, "Where Should I Go Now?", is aimed at the sort of person who is so hungry for knowledge that they want to know more, and more, and more! If you are such a person, then hopefully the pointers you’ll find in this appendix will be just what you need!
Vocabulary
I have tried to follow the naming conventions introduced by [meszaros2007]. As far as I know, the terms he introduced (or gave definitions for) have "caught on" within the developer community, and are currently in use by most developers.
Exercises
Tell me and I forget. Teach me and I remember. Involve me and I learn.
— Benjamin Franklin
Most sections of the book contain some exercises. Remember, they are there to be done, not to be read! No excuses! ;)
Notes On Code Examples
Throughout the book there are many code examples. A few notes about them:
•For the sake of brevity, in many code examples some language constructs - like the use of "private final" variable modifiers – have been omitted. But in general I have tried to write the code adhering to all possible good practices and standards.
•Likewise, auto-generated IDE comments have been removed.
•Not all method names follow the naming pattern suggested in Section 9.2. This is due to the fact, that some of them are here to illustrate some specific case, and their name informs about their purpose.
xi
Preface
•Some method names have had to be shortened as otherwise they would not have been correctly wrapped in the PDF version of the book. This is a shame, as I was really attached to them. :)
Icons
The following icons appear within the text:
A helpful tip.
An additional note.
Warning, danger ahead!
All three icons were designed by Webdesigner Depot (http://www.webdesignerdepot.com/).
Book Site
The official book site is on http://practicalunittesting.com. Please visit it for news and information on downloadable extras etc.
Code Download
All examples from the book (including exercises) are available online. Please visit http:// practicalunittesting.com for detailed information on how to acquire them.
Piracy
I guess the book is already out there…. Well, I take that as a compliment: apparently it must be worth stealing. But of course, you won’t be left with that nasty taste in your mouth if you buy it rather than stealing it!
xii