Book review: Sujoy Acharya – Mastering unit testing using Mockito and JUnit

Some weeks ago, I was contacted by Packt Publishing to write a review about the book above. Without any further introduction, let’s just jump in and see the pros and cons of this book.

Mastering unit testing using Mockito and JUnit is a pretty new book, it was published in July 2014.

Right in the first chapter, the author digs deep into the capabilities of JUnit 4. This is a very thorough analysis of the JUnit API, starting from basic things (like how to write a basic test case) and gradually moving towards more and more advanced topics (test categories, expected exceptions). Anything you’re ever going to use from JUnit is described here – and much more. While reading this chapter I had a feeling that if the reader is an expert, chances are high that they’ve already met most of those method calls and annotations; if they’re new to unit testing, then this chapter may be somewhat too fast.
Every single aspect (method, annotation etc.) is backed by some example code, but unfortunately these problems have little to do with real life applications (like assertTrue(true)). Quick note: the book uses the when_something_then_something naming convention for tests. I like this very much, this is my favorite too, as test names become much more readable.

Chapter 2 introduces automated build tools such as maven (ant, gradle) and Jenkins. I think this is a very good idea, as nowadays such tools are compulsory for a software engineer. However, three build tools (maven, ant and gradle) described in detail (I really mean in detail: how to download and configure tehm, how to put together a simple project) is a bit too much. (I think most readers want to be true masters of unit testing, and not of different build tools. To describe the concept along with an example is awesome and would have been more than enough).

Chapter 3 is very short compared to the others. It describes the test doubles – as defined by Gerard Meszaros, which is really a prerequisite to mocking. Many times people fail to see the difference between all the types of test doubles, so this chapter is very welcome.

Chapter 4 is all about mocking with Mockito. It again dives deep into Mockito with all its annotations, API methods and capabilities.  Although similar to Chapter 1, this chapter introduces a more complex example (manipulating stocks), through which it unfolds different aspects of Mockito. There are very nice tips in this chapter, like inline stubbing (saves a lot of code lines) or configuring mock default behaviors for mocks. I’m looking forward to putting in practice some of the ideas described here.

Chapters 5 and 6 will take you to the world of code coverage and code analysis tools. This is again, very cool idea to talk about in conjunction with unit tests. Maybe I would have liked it more right after chapter 2, so Mocito and its usage could have been one after another.

Chapters 7 and 8 are about using Mockito in real life. Chapter 7 is about testing web application, while Chapter 8 talks about testing the data tier. These, indeed are tough things to handle in real projects, so I like it very much that these chapters made it into the book. However, I think there is a slight focus loss here; these two chapters shouldn’t put that much attention on Spring (MVC and JDBC Template), but rather on general, technology independent problems. Sometimes  I felt like I was reading a book on Spring, with some unit testing and not the other way around.

My favorite parts were the last two chapters. Chapter 9 talks about problems that pop up every single day while fighting huge legacy code bases. Those things described there happen exactly as presented – I encountered almost each and every of them when I was a maintenance guy. The book offers practical solutions on how to overcome these obstacles and get legacy code base under test. This chapter is an awesome one, everybody should know and practice those tricks.

Chapter 10 is about best practices when it comes to unit testing. This chapter is really for the inexperienced, who have just  met unit testing but are not familiar with all the good practices about the framework. This chapter should be a very good starting point for junior programmers at the beginning of their career.

Mastering unit testing using Mockito and JUnit has got pretty cool tips and tricks, very thorough analysis of the frameworks and practical applications for everybody out there. One thing I particularly liked is that the book offers a very good overview on all the different reasons why a piece of code becomes hard to test. Nevertheless, I can’t really figure out who is this book for. It is too fast paced for absolute beginners, but somewhat too obvious for experienced engineers – in my honest opinion, some parts may miss the targeted audience.

Having said all these, I’m rating this book 3 out of 5.

Agile principles: feedback

Quick and adequate feedback is important. It’s one of the core principles of agile, after all. However, people keep forgetting about its importance and value. They treat feedback related tasks like timewasters; they would even tell at standups “providing feedback is blocking me” if they could.

What is the best and quickest way of providing feedback – audience say with me – yes, code review. When I hear people presenting results of reviews, most of the times, it’s like: “well it’s ok with me…” I guess this effect can be tracked down to two reasons: laziness and a psychological factor.

Laziness is the obvious one. In order to produce quality feedback one needs to be very careful and thorough. Each and every new code line (and not only – I’ll get back to this immediately) needs be parsed, understood and processed. Are variables and methods named in a self explanatory way? Are methods and classes short enough to be understood with ease? Are unit tests in place, are they really testing the functionality, or are they coverage-increaser-liars? Too many questions to be answered in ten minutes. And in most cases people spend just that much time reviewing (usual case, usual developer, the nature of task to be reviewed does not matter). In order to produce the best possible review comments, some systems thinking is also implied. That’s why not only new code has to be processed; a new question arises: how well it fits into the legacy system? Which can be further broken down into a series of “what if” questions. What if we run the code in a multithreaded environment? What if an exception is thrown? What if we refactored things into several classes/methods? Is it possible, that any part of the new code has already been implemented? (that doesn’t start with “what if”, but happens very often in large systems).

The other reason why we don’t do review thoroughly enough, is that we don’t want to hurt authors’s feelings. Many people think like: “well, I could mention this as a possible comment, but what if they take it as an insult?”. Wrong question. In my opinion any suspicious code part has to be mentioned. Of course in a friendly and supportive manner, and not in “what the hell is this bullshit, dude?” style. Some people will take it personally anyway, but they’ll eventually realize it’s for everyone’s sake.

Further reading on producing quality feedback through code review: Zsolt Fabók’s Basics of code review