Tomek Kaczanowski writes that the idea behind its “Bad Tests, Good Tests” book is “to present test code snippets and discuss ways of making them better.” To achieve this goal, he explores a large amount of code and tests to discuss all the issues that you can meet in your software testing activities.
The book discusses how to write unit tests that are strong, maintainable and easy to read. The book mixes parts the concepts needed to achieve these objectives with many examples that contain real Java code of real applications. It is well structured and easy to read with a casual style. Java testing tools (JUnit, Mockito) specific issues are also discussed in the book. I liked the fact that helpful tips and important things to remember were put in evidence. Many code parts discussed in the book can also be found on github: https://github.com/tomekkaczanowski/bad-tests-good-tests-code
Although this book has a stronger appeal for Java developers, I will recommend it to every software developer as many of its advices can be applied to other programming languages. As there is a free pdf version available, your risk of reading it is minimal.
Reference: Bad Tests, Good Tests, Tomek Kaczanowski, http://practicalunittesting.com/btgt.php
Quotes
The worrying thing about writing tests is that there are numerous accounts of people introducing tests into their development process and… ending up with even more junk code to support than they had to begin with! Why? I guess, mainly because they lacked the knowledge and understanding needed to write good tests: tests, that is, that will be an asset, not a burden.
Testing frameworks aren’t very complex; however, there are always some gotchas. Make sure to read some documentation.
[…] depending on the type of application you write, some types of test (unit, integration, end-to-end, performance, etc.) are probably going to be more important than the rest. If you put too much effort into unit testing, but not enough into end-to-end tests, you might encounter the sort of issues we did. On the other hand, if you do things the other way around, you’ll face different issues – related to some untested corner cases and to the maintenance of many (heavy and slow) end-to-end tests. Kudos to those who are able to come up with the right proportion of unit, integration and end-to-end tests!
[…] when it comes to giving appropriate names to methods and variables in production code, we are usually very successful. However, when it comes to tests, we jettison these good habits and often perform poorly. I suspect this is because in tests it is quite normal to have a few objects of the same type, resulting in simple naming schemas like productA, productB, productC etc. Sometimes this is good enough, but sometimes it could be much improved.