Dagger 2, MVP and Unit Testing (PIT Mutation Testing) – Part 4

The previous three articles[1] showed an introduction to Dagger, MVP pattern, Espresso and more. This article focuses on introducing a powerful test coverage technique for ensuring that the app unit tests are strong enough.

Introduction to Mutation Testing

One of the golden standard test coverage techniques is mutation testing. The main idea of mutation testing is to perform byte code modifications (mutations) to your original app source code and then run your app unit tests to check if they are strong enough to fail as a result of these mutations.

The byte code changes in Mutation Testing are named as faults (or mutations). After applying the source code changes, if your tests fail then the mutation is killed, and if your tests pass then the mutation is lived.

So in summary, If your tests fail by source code mutations then this means that your tests are really strong, if your tests pass then this means you need to modify your tests to make them strong enough (The quality of your tests can be gauged from the percentage of mutations killed).

Why we need Mutation Testing

Mutation tests have an advantage over Traditional test coverage (i.e line, statement, branch etc) because it does not only measure which code is executed by your tests but also it checks that your tests are actually able to detect faults in the executed code. This gives a strong measurement to your developed unit tests.


PIT is one of the mutation testing systems for Java. It has several advantages:

  1. Fast to execute.
  2. Integrated with Java build tools (Ant, Maven and Gradle).
  3. Active.

More information about PIT can be found in:

Android Integration

Unfortunately, the official PIT Gradle plugin does not work fine with Android Gradle projects:

However, thanks to one of the community member, this support is now possible using this fork:

Application Configuration

In order to configure Android PIT plugin with our Android Dagger app:
1. Add PIT plugin to your top-level build.gradle file:

classpath 'pl.droidsonroids.gradle:gradle-pitest-plugin:0.0.3'

2. Configure PIT plugin in your app build.gradle file:

pitest {
   targetClasses = ['com.test.xyz.daggersample1.ui.presenter.*']  /* specify target classes to be mutated */
   excludedClasses = ['**Factory*'] /* Exclude Dagger generated classes */
   pitestVersion = "1.1.0" 
   threads = 4 /* specify number of threads */
   outputFormats = ['XML', 'HTML'] /* specify output format */

Checking Results

After configuration, finally, we can execute PIT tests by running:

./gradlew pitest

You can pick the PIT tests report under build/reports/pitest.

The following figure shows the mutation testing report in our Dagger sample:
PIT Report

The following figure shows survived and killed mutants:

FYI, in the mutation report, Light green shows line coverage, dark green shows mutation coverage, Light pink show lack of line coverage, and dark pink shows lack of mutation coverage.

Source code

App Source code is available in:

Top-level Gradle file PIT configuration:

Module-level Gradle file PIT configuration:

In our next article, let’s see how to kill these survived mutants which makes our tests not strong enough!

[1] Previous articles:

Back from GeeCON Poland 2014


I just get back from GeeCON that was held in Krakow, Poland 14-16 May 2014. The conference organization was fantastic and there were a lot of attendees in the conference sessions. IMO, GeeCON is really the biggest Java Conferences in the Central-Eastern Europe as it had 1100+ attendees.


I had the chance to present “Jasmine Automated Tests for JavaScript” in 15 May, the session had many attendees and I was really amazed by the energy, enthusiasm, and responsiveness of the attendees during the session.



The session went great and I was glad to give a free copy of my JavaScript Unit Testing book to one of the attendees who answered a JavaScript quiz at the end of my session.

I uploaded my session below:

Finally, I would like to thank all the organizers of this conference, especially Adrian Nowak (@adrno), Adam Dudczak (@maneo), Marcin Gadamer (@marcingadamer), and certainly all of the wonderful guys behind this conference.

[OT] Krakow is a wonderful modern city, if you plan to go there then do not miss visiting Ojców Garden Krakow, Wawel Royal Castle, and generally Old Krakow city. I attached below some of the photos below:

1. Krakow, The Old City, 16 March 2014:

2. Wawel Royal Castle, Krakow, 16 May 2014:

Back from JavaOne China 2013

JavaOne China

JavaOne China

I just get back from JavaOne China that was held in Shanghai 22-25 July 2013. JavaOne China is one of the biggest Java Conferences in Asia. The conference organization was good and there were a lot of attendees in the conference sessions.

JavaOne China

JavaOne China

I had the chance to present “Efficient JavaScript Unit Testing” in 23 July, the room of the session was full of attendees and I was really amazed by the energy, enthusiasm, and responsiveness of the attendees during the session.

Photo with Chinese Developers

Photo with Chinese Developers

The session went great and I was glad to give a free copy of my JavaScript Unit Testing book to one of the attendees who answered a JavaScript quiz at the end of the session.

I uploaded my session below:

Aside from the conference, Shanghai is a modern city that has many good places to visit, I had the chance to visit three places there:
1. Yuyuan Garden and Old Town Area:
Yuyuan Garden Photos

2. Jing Temple:
Jingle Temple Photos

3. Oriental Pearl TV Tower:
Oriental Pearl TV Tower Photos

What the JavaScript Unit Testing book covers?

The JavaScript Unit Testing book is a comprehensive practical guide that illustrates in details how to efficiently perform and automate JavaScript testing for web applications using the most popular JavaScript unit testing frameworks.

The book starts by explaining the concept of JavaScript unit testing and by exploring the bits of an interactive Ajax web application. Throughout the book chapters, the JavaScript part of the web application is tested using popular JavaScript unit testing frameworks (Jasmine, YUITest, QUnit, and JsTestDriver). The book illustrates how to generate JavaScript test reports, how to automate running the tests in the build and the continuous integration environments, and how to make all of the mentioned JavaScript unit testing frameworks work together in order to test the web applications in the most efficient way.

After reading this book, you will learn everything you need to know in order to make efficient JavaScript tests for the web applications. You will learn how to generate test and code coverage reports, how to automate running the JavaScript tests, and the bits of the JavaScript testing by following the book practical hands-on detailed examples.

You can order the book from: http://www.amazon.com/dp/1782160620/.

Finally, I would like to thank all of the persons that worked with me in order to produce this book (Acquisition Editor, Commissioning Editors, Technical Editors, Copy Editors, Project Coordinator, Proofreaders, Graphics Designers, Production Coordinator) and certainly the technical reviewer of this book Allan Lykke Christensen.

“Efficient JavaScript unit testing” video session in CONFESS 2012

This video provides a presentation about how to make efficient JavaScript unit testing. I presented it in the CON-FESS 2012 international conference which was held in Leogang, Austria. I wish it can be useful.

See the presentation with the slides on Parleys.com

See the presentation with the slides on Parleys.com

and I included below the presentation:

“Efficient JavaScript unit testing” presentation in CONFESS 2012

I just got back from the International technical conference CONFESS 2012 which was held in Leogang, Austria. The conference was very cool, the hotel and the city were fantastic, the quality of the sessions and the speakers were great.

Now, I got finally some free time to share with you my presentation about my efficient JavaScript unit testing. I hope it will be useful for you. Once I get the video session, I will definitely share it with you as well.

Have a nice time.

Converting the JsTestDriver coverage files to HTML Reports

In this post, I will show you the detailed steps that are required to convert the JsTestDriver LCOV coverage files to HTML reports. Before reading this post, I recommend you to read this post first “Generating Test Reports using JsTestDriver“.

First of all, you need to download the LCOV visualizer from: http://ltp.sourceforge.net/coverage/lcov.php.

Then install the downloaded rpm file in your Linux Redhat environment using the following command line:

rpm -i lcov-1.9-1.noarch.rpm

To check that the tool is installed correctly, run the genhtml command, you should see the following output:

After that you can start running the HTML report generation command:

genhtml jsTestDriver.conf-coverage.dat

Note that you have to make sure that the paths of the JavaScript source files are correct in the jsTestDriver.conf-coverage.dat file, otherwise you will face the genhtml: ERROR: cannot create directory !

You should see the LCOV visualizer tool is generating the testing report as indicated in the screenshot below:

After the successful generation of the HTML report, click the index.html file in the parent folder to see the HTML report:

As shown in the previous screenshot, the report covers the three main code coverage criteria:
1. Line coverage (statement coverage) which represents the percentage of the source code statements that are tested.
2. Function coverage which represents the percentage of the functions that are tested.
3. Branch coverage which represents the percentage of code branches that are tested.

I attached here the test report files for your reference.

Resolution of genhtml: ERROR: cannot create directory !

When using the LCOV Visualizer tool to generate the HTML reports from the JsTestDriver lcov coverage (.dat) file (usually jsTestDriver.conf-coverage.dat) using the genhtml command:

genhtml jsTestDriver.conf-coverage.dat

You may find the following error:

mkdir: cannot create directory `': No such file or directory
genhtml: ERROR: cannot create directory !

This error happens because the paths of the JavaScript files are not correct in the (.dat) file. To fix this error, open the (.dat) file, you will find its content as follows:


Then edit the SF: values with the correct paths of the JavaScript source (and testing) files and execute the genhtml command again to generate the HTML testing report.

Five Steps to use Apache Cactus with WebSphere Application Server 7

This post illustrates setting up the Apache Cactus on WebSphere 7.0 to test some JPA managers in an existing web application.

Let’s go through the steps, so you can do them directly in maximum 5 minutes:

1. Download the Apache Cactus 1.8.0.zip from here.

2. Place ONLY the following jars in the lib folder of your web application:

    2.1. aspectjrt-1.5.3.jar
    2.2. cactus.core.framework.uberjar.javaEE.14-1.8.0.jar
    2.3. cactus.integration.ant-1.8.0.jar
    2.4. cactus.integration.shared.api-1.8.0.jar
    2.5. cargo-ant-0.9.jar
    2.6. cargo-core-uberjar-0.9.jar
    2.7. commons-codec-1.3.jar
    2.8. commons-httpclient-3.1.jar
    2.9. commons-logging-1.1.jar
    2.10. httpunit-1.6.jar
    2.11. js-14.jar (You will have to download this file manually to avoid OutOfMemory Exception on WebSphere).
    2.12. junit-3.8.2.jar
    2.13. nekohtml-1.9.6.jar
    2.14. org.mortbay.jetty-5.1.9.jar
    2.15. xbean-1.0.3.jar (You will have to download this file manually to avoid OutOfMemory Exception on WebSphere).

3. Copy the following servlets declaration to your web.xml file:

<!-- [Start] Cactus Configuration -->
<!-- [End] Cactus Configuration -->

4. Write your web test cases.

public class TestServlet extends ServletTestCase {
    public void testCreatePerson() {
        try {
            FacesContext  facesContext  = JSFUtil.getFacesContext(config.getServletContext(), request, response);
            PersonManager personManager = (PersonManager) JSFUtil.getManagedBean(facesContext, "personManager");            
            Person person = new Person();
            person.setPersonName("Hazem" + System.currentTimeMillis());
            person.setPersonNationalId(System.currentTimeMillis() + "");
        } catch (Exception exception) {
    // Other test cases ...

As you notice, Cactus is much similiar to JUnit, Your web testcases class should just extend the (org.apache.cactus.ServletTestCase).

5. Finally, deploy the web application war to the WAS 7.0, and access your web testcases class through the (ServletTestRunner) by using the following URL:

As you see here, you just set the suite parameter to the fully-qualified name of your web testcases class.

Here is the sample output:

If you want a nicer output, then make sure to include the cactus-report.xsl [This file is included in the sample] directly under the (Web Content) folder of your application, and add the xsl parameter as follows:

Here is the cooler output:

I included all of the project source code including the dependency jars in the following zip file for your reference. I wish that this tip can be helpful to you.

Running Jasmine on the top of the JsTestDriver test runner

In the previous post, I give you a kickstart about the Jasmine JavaScript unit testing framework. In this post, I will show you how to integrate the Jasmine framework with the JsTestDriver. You will combine the best of them, the power of Jasmine pretty syntax and the power of JSTD test runner.

The JsTestDriver is not only a JavaScript unit testing framework but it is also a test runner that can host other JavaScript unit testing frameworks through adapters. The JsTestDriver can host the following JS unit testing frameworks and more:
1. QUnit.
2. Jasmine.
3. YUI UI Test.

First of all to be able to run Jasmine on the top of the JsTestDriver runner, you need to download the Jasmine JSTD adapter from here: https://github.com/ibolmo/jasmine-jstd-adapter.

In order to run Jasmine test suites on the top of JSTD test runner, you need to load the adapter and the source files before the test files as follows in the jsTestDriver.conf file:

server: http://localhost:9876

  - jasmine/lib/jasmine-1.1.0/jasmine.js
  - jasmine/lib/adapter/JasmineAdapter.js  
  - js-src/Basics.js
  - js-test/BasicsSpec.js 

After that you can start the JSTD server, and then run the test cases as usual. I attached below the screenshot of the Jasmine tests on the top of the JSTD test runner.
jstd jasmine screenshot

I attached here the project source for your reference.