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

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:
http://pitest.org/

Android Integration

Unfortunately, the official PIT Gradle plugin does not work fine with Android Gradle projects:
https://github.com/szpak/gradle-pitest-plugin

However, thanks to one of the community member, this support is now possible using this fork:
https://github.com/koral–/gradle-pitest-plugin

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:
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:
https://github.com/hazems/Dagger-Sample/tree/pit1/app/src/test/java/com/test/xyz/daggersample1/ui/presenter

Top-level Gradle file PIT configuration:
https://github.com/hazems/Dagger-Sample/blob/pit1/build.gradle

Module-level Gradle file PIT configuration:
https://github.com/hazems/Dagger-Sample/blob/pit1/app/build.gradle

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

[1] Previous articles:
http://www.technicaladvices.com/2016/03/05/an-introduction-to-dagger-2-android-di-part-1/
http://www.technicaladvices.com/2016/03/09/an-introduction-to-dagger-2-android-di-part-2/
http://www.technicaladvices.com/2016/04/07/dagger-2-mvp-and-unit-testing-android-di-part-3/

Reverse Engineering Android app binaries (APK) for Legitimate Analysis

Android APK
Finally, I have some chance to get back to blogging since I was very busy last month. Now, let’s go in the details in our today’s topic.

Sometimes, you may have a situation to reverse engineer your existing APKs for legitimate analysis reasons such as making queries on the app source (including used third party libraries) for getting more inside information.

This post shows you how to revere engineer an existing APK for the purpose of such good reasons (again for purpose of *good* reasons).

Detailed way / Using Mainly Three Tools

In order to reverse engineer an APK file from its source, you need to do the following:

  • Exploding APK
  • Extracting Java Classes
  • Decompiling Java Sources
  • Inspecting APK Content

Now, let’s go through them quickly.

Exploding APK

First of all, we need to explode the apk file to mainly the apk resources (assets, libraries, and manifest files).

In order to achieve this step, you need to download and use ApkTool which can be found in:
https://ibotpeaches.github.io/Apktool/

After downloading the jar, execute the library jar as follows.

java -jar apktool_2.2.0.jar decode --no-src myApk.apk

Note that if you do not specify the no-src parameter, then the Apk tool will decode sources and generate SMALI code (Not Java).

Extracting Java Classes

The second step is to convert the APK DEX file(s) into Java jar file(s). You will be find the DEX files whose names
are following classes(i).dex pattern under the exploded apk file directory (note that if your apk is multi-dex then beside the main classes.dex file, you can find classes2.dex, (and/or) classes3.dex … and so on).

In order to make this extraction, you can use a very good tool called (dex2jar) which can be found below:
https://sourceforge.net/projects/dex2jar/

Download the zip file and extract it, then run the dex2jar tool from command line as follows (assuming
that the dex2jar directory is directly located in the same level of the DEX file(s)).

sh d2j-dex2jar.sh ../myApk/classes.dex -o ../myApk/src.jar

Decompiling Java Sources

After having the jars, now we can simply decompile these jars into original Java sources. For this, we can use the command line Java Decompiler which is available in:
https://github.com/kwart/jd-cmd

For every jar we have, we can simply decompile it by running jd-cli as follows.

./jd-cli src.jar

Inspecting APK Content

Finally, we can inspect the APK content as much as we wish. For example, we can get all the strings in the content which are following a URL pattern by executing the following grep command on the exploded apk root folder.

grep -Eo '(http|https)://[^/"]+' -R .

This command will output the complete list of files whose contents are matching this grep regular expression.

Fast way / Using Jadx

Jadx is a powerful tool for directly converting an APK to its original sources, it can be found in:
https://github.com/skylot/jadx
So for our myApk.apk, all what we need to get its original source is to use Jadx tool as follows.

./jadx myApk.apk 

Executing the previous command will do all the previous explained three steps for you.

Now, we are done, see you in the next post.