According to the author, 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. Despite the Java/TestNG/Mockito orientation that the title might suggest, the book contains a high percentage of general unit testing knowledge that can be applied (mostly) independently of the language and tools that you are using.
The book discusses general topics of unit testing and mocking, providing examples created with the TestNG and Mockito tools. My preferred part is the one dedicated to test maintainability and test code quality that deals with aspect of software testing that are less visible in the available literature. The book is well written and structured, with a dose of humor. Exercises are suggested and a summary is provided at the end of each chapter.
I also liked the approach of the author to have an open view on unit testing and presenting all the available choices for testing strategies or tools selection instead of just pushing his own opinion. This book is highly recommendable to all software developers interested in unit testing, particularly if you are working in a Java context.
Reference: ” Practical Unit Testing with TestNG and Mockito”, Tomek Kaczanowski, 448 pages, IBSN 978-8393489305
Book Web Site: http://practicalunittesting.com/
In general, tools for testing are very simple to use. That is good news, isn’t it? But be warned – there is a catch! This deceptive ease of use leads many developers to assume that they know how to test, just because they can use testing tools – i.e. they are able to write a few lines of JUnit code. This is plainly wrong. Tools can be used mindlessly, or they can be used by a skilled hand. They can dominate you or they can become your obedient servants. The point is to grasp the ‘why’ and the ‘what for’, so that you know when to use (or not use) them.
If you think about it, you will realize that writing a test after a bug has been found really amounts to a test-first approach. You write a test which fails (because you want to mimic the bug), and then you implement the code.
Applications maintainability – the holy grail of software development! We write code every day, trying to make it so good it will withstand the test of time. We hope that we, or our colleagues, working with this code sometime in the future, will be able to understand it at a glance. We hope to be able to introduce changes easily without causing chaos throughout the entire application. We should write our tests with the same attitude, trying to make them maintainable. Why? Because, as we have already discussed, they play a crucial role in supporting and documenting our production code.
Another point worth remembering is that there is a strong relation between the quality of your production code and test code. Having good, clean, maintainable tests is definitely possible. The first step is to write cleaner, better designed and truly loosely-coupled production code. If the production code is messy, then there is a considerable likelihood that your tests will also be. If your production code is fine, then your tests have a chance of being good, too. The second step is to start treating your test code with the same respect as your production code. This means your test code should obey the same rules (KISS, SRP) that you apply to production code: i.e. it should avoid things you do not use in your code (e.g. extensive use of reflection, deep class hierarchies, etc.), and you should care about its quality (e.g. by having it analyzed statically, and put through a code review process).