Mastering Unit Testing Using Mockito and JUnit

Book Review: Mastering Unit Testing Using Mockito and JUnit

I was asked by Packt Publishing to write a review blog post about the new book Mastering Unit Testing Using Mockito and JUnit by Sujoy Acharya (released in Jun 2014). As I am passionate about all topics around testing or continuous development, I got exited. Nice side effect of this is that I could read this book for free ;). Book is 314 pages long. Divided into 10 chapters.

Preface

Summarizes why reader wants to test. Also why wants to have automated feedback loop. But there was very strong statement: “Greenfield projects always follow test-driven development to deliver maintainable and testable code.” Of course author probably wrote this before test first / test last battle. I am personally also TDD infected but there are definitely situations where it doesn’t make sense to do test first or test at all (e.g. prototyping). Also we should accept existence of test last approach. There are certainly very strong TDD opponents:

Chapter 1: JUnit4 – A Total recall

Guides reader how to create simple project in Eclipse. Leads him through JUnit features. It starts with basic fundamentals. Later in the chapter are described advanced parts of JUnit API. Some of these parts of the API should be used rarely or not at all (e.g. test methods ordering). This would be worth mentioning for beginners.  I wasn’t very excited because I am TestNG user. If you ever wrote some unit tests you probably would want to skip this chapter. Surprising for me was comparison of JUnit 4 @Before annotation with JUnit 3 setUp(). JUnit 4 is already 8 years old.

Chapter 2: Automating JUnit Tests

Elaborates about Continuous Integration. Also provides basic information about Gradle, Maven and Ant. Demonstrates very simple configurations of each build tool and how they run tests. Lastly touches simple Jenkins integration with each mentioned tool. Shame that configuration of examples across the book weren’t driven by any of this build tools.

Chapter 3:  Test Doubles

Brief explanation of theory behind faking dependencies of testing object. It also contains examples of each type (without usage of any testing framework so far).

Chapter 4: Progressive Mockito

Demonstrates Mockito syntax on examples. It goes through basic and also advanced Mockito features. At the end of the chapter is mentioned BDD (Behavioral driven development) style of testing. The only disturbing moment was manual inclusion of dependencies in example project configuration. Build tools were discussed in Chaper 2.

Chapter 5: Exploring Code Coverage

Author explains what code coverage means. After that shows some ways how to measure code coverage from Eclipse. I was surprised that he still accepts Cobertura as relevant tool, because Cobertura is dead project now. Last version was working only for Java 6. Java 6 was marked as “End of life” more that a year ago. That is why integration examples of Cobertura with Ant and Maven aren’t very useful. Examples how to integrate them with JaCoCo would be much more appropriate. I integrated JaCoCo with Maven in the past. It’s definitely doable.

Chapter 6: Revealing Code Quality

This chapter shows three very useful Java static code analyzers

  • PMD
  • FindBugs
  • CheckStyle

Than it introduces SonarQube and its integration with mentioned build tools. It is very handy tool for monitoring technical depth on the project.

Chapter 7: Unit Testing the Web Tier

Some examples how you can test

  • Servlets
  • Spring MVC

But Spring MVC examples with Spring Test’s MockMvc library are missing. Examples in this chapter contain only plain Mockito + JUnit libraries. Readers should definitely take a look at MockMvc capabilities, because they are much more handier than explained approach.

Chapter 8: Playing with Data

This time author focuses on DAO layer. My personal opinion is that mocking Connetion or PreparedStatement in tests isn’t quite right. You can have test passing, but when you execute SQL statement against DB it can fail on some SQL error. I prefer to have integration tests for DAO layer.

Chapter 9: Solving Test Puzzles

Discusses constructs known as testability killers and some approaches how to solve them. I also discussed this topic in blog post series. I am glad that author doesn’t suggest usage of PowerMock. Rather takes the path of changing production code to enhance testability. Totally agree. Finally it shows example of TDD style of programming. Shame that this is the only example in the book where test is introduced before production code. So all other examples doesn’t follow TDD.

Chapter 10: Best Practices

This chapter dives into some common pitfalls reader can fall during writing the tests. Such advices are always good to keep in mind.

Conclusion

“Mastering Unit Testing Using Mockito and JUnit” book declares that was written for advanced to novice software testers and developers who use Mockito and JUnit framework. I would say that is only for beginners. It is mainly because book is covering wide range of topics around testing and its automation. There isn’t enough place dive deeply. Positive is covering nearly all aspects of professional unit testing. So it is very good start for developers that are willing to explore benefits of automated feedback loop. Author takes approach of hands on examples, so it is much better to read it next to the computer.

eclipse-pmd

eclipse-pmd – New PMD plugin for Eclipse

I am Eclipse user. So when I wanted to analyze my code by PMD, I needed to use “PMD for Eclipse” plugin. This plugin used to be very buggy, which was enhanced in later versions (currently 4.0.3). But the performance is really bad sometimes. Especially when you are dealing with relatively big codebase and have option “Check code after Saving” on.

ecplise-pmd plugin

So when I realized that there is new alternative PMD plugin called eclipse-pmd out there I evaluated it immediately with great happiness.

Installation uses modern Eclipse Marketplace method. You just need to go “Help” -> “Eclipse Marketplace…” and search for “eclipse-pmd”. Than hit “Install” and follow instructions.

After installation I was a little bit confused because I didn’t find any configuration options it general settings (“Window” -> “Preferences”). I discovered that you need to turn on PMD for each project separately. Which make sense, because you can have different rule set per project. So to turn it on, right click on project -> “Preferences” -> “PMD” (there would be two PMD sections if you didn’t uninstall old PMD plugin)-> “Enable PMD for this project” -> “Add…”. Now you should pick a location of PMD ruleset file. pick-ruleset

Unlike old PMD plugin, eclipse-pmd don’t import ruleset. It is using ruleset file directly. This is very handy, because typically you want to have it in source control. When you pull changes to ruleset file from source control system, they are applied without re-import (re-import was needed for old PMD plugin).

Problem can be when you (or your team) don’t have existing ruleset. I would suggest to start with full ruleset and exclude rules you don’t want to use. Your ruleset would evolve anyway, so starting with most restrictive (default) deck make perfect sense for me. Unfortunately eclipse-pmd plugin doesn’t provide option to generate ruleset file. So I created full ruleset for PMD 5.1.1 (5.1.1 is PMD version not plugin version). I have to admit that it was created with help of old PMD plugin.

You can see that I literally included all the rule categories. I would suggest to specify your set this way and exclude/configure rules explicitly as needed. Here is link to PMD site that explains how to customize your ruleset. This approach can be handy when PMD version will be updated. New rules can appear in category and they will be automatically included into your ruleset when you are listing categories, not rules individually. But you have to keep eye on new rules/categories when updating PMD version anyway, because categories often change with new PMD version.

So now we should have rulset configured and working. Here are some screen shots of rules in action:

When you hover over left side panel warning:

eclipse-pmd

When you hover over problematic snippet:

eclipse-pmd

When you do quick fix on problematic snippet:

eclipse-pmd

Generating suppress warning annotation for PMD rules is very nice feature. It also provide quick fixes for some rules. Take a look at its change log site for full list.

These PMD warning sometimes clash with Eclipse native warnings, so there is possibility to make them more visible. Go to “Window” -> “Preferences” -> “General” -> “Editors” -> “Text Editors” -> “Annotations” and find “PMD Violations”.

eclipse-pmd

Here you can configure your own style of highlighting PMD issues. This is mine:

eclipse-pmd

To explore full feature list of this plugin take a look at its change log site.

There are some features in old plugin I miss though. For example I would appreciate some quick link or full description of the rule. Short description provided is sometimes not enough. I encourage you to take a look at full PMD rule description if you are not sure what’s source of the problem. You will learn a lot about Java language itself or about libraries you are using. Quick links would help a lot in such case.

Another behavior I miss is full list of PMD violations for current file.  Also some rules doesn’t use code highlighting (only side panel markers). It is sometimes hard to distinguish between compiler and PMD issues. This is problem for me because our team doesn’t use JavaDoc warnings but I do. So I get a lot of JavaDoc warnings from code written by teammates. And sometimes I can miss PMD issue because it is lost in JavaDoc warnings. (Fortunately SVN commit is rejected if I forget to fix some rule).

Conclusion

This plugin enhanced my Eclipse workflow. No more disruptions because of endless “Checking code…” processing by old plugin.