Java unit testing in Android
Having spent 1.5 years working on PHP projects with very high test coverage and frequent test runs, it strikes me with great surprise that to achieve the same thing in Android is not as straightforward.
One of the best advantages of having unit tests is that you can get instant feedback on your changes, whether your code does what it's supposed to do, or if it breaks existing behaviour. In an ideal environment, it should take only a few seconds to verify your changes. Sometimes it's too fast that people argue that as disadvantages.
Surprisingly, it is not the case for Android, which was not designed with unit testing in mind. You would need an emulator or a real device to run your tests! Say what? Every test run now adds at least 30 seconds of overhead. Goodbye, all the best TDD!
Of course there are alternative ways to make Android tests run faster, but what if I only need to test my Java logic that has nothing to do with Android? Why do I need a device to test that logic? Sure, one can extract all pure Java code into a library so he can test them, but with product managers chasing after you, it's not always the best choice. But worry no more, with a little bit of customization to Gradle build system for Android, that dream of TDD your Android projects is getting closer.
Gradle 1.11 with Android plugin 0.9.0 and Jacoco plugin. Java plugin for Gradle supports unit testing out of the box. Applying Java plugin will give you a test task that you can use to run all the tests. Jacoco plugin complements that by generating code coverage report, without any special setup. It just works!
To do the same thing with Android, you will need to apply Java plugin together with Android plugin. But you will soon realize that it's not possible, they are not compatible. So that leave you with only option of making a test task by yourself. Luckily, it is not that difficult:
Run Java unit tests with Gradle
First, you need to tell Gradle where you put your test code. Define a sourceSet, here we call it unitTest.
sourceSets { unitTest { java.srcDirs = ['test'] resources.srcDirs = ['test'] } }
Then you need to tell Gradle what you need to compile your sourceSet. Ideally test compilation should be separate from production compilation. Here we add a custom configuration called unitTestCompile, which extends from compile, since you obviously need to compile your code to test it! The inclusion of junit is compulsory, while other libraries are needed if you use some Android interfaces, mock classes or parameterize your tests.
configurations { unitTestCompile { extendsFrom compile } } dependencies { compile project(':your-project') compile project(':your-project-dependencies') unitTestCompile 'junit:junit:4+' unitTestCompile 'com.google.android:android:4.1.1.4' unitTestCompile 'org.mockito:mockito-core:1.9.5+' unitTestCompile 'pl.pragmatists:JUnitParams:1.0.2+' }
With everything compiled and ready to run, let's create our own Gradle's test task. Here the trick is to extends the Test class that is readily available in Gradle API, which executes JUnit tests. We call our extended task 'unitTest'. It depends on assemble to make sure that it will run after we have rebuilt everything.
def debugClassesDir = "${buildDir}/classes/debug" task unitTest(type: Test, dependsOn: assemble) { testClassesDir = sourceSets.unitTest.output.classesDir sourceSets.unitTest.compileClasspath += files(debugClassesDir) sourceSets.unitTest.runtimeClasspath += files(debugClassesDir) project.configurations .collectMany { it.allDependencies } .findAll { it instanceof ProjectDependency } .each { dependenciesBuildDir = "${it.dependencyProject.project.buildDir}/classes/debug" sourceSets.unitTest.compileClasspath += files(dependenciesBuildDir) sourceSets.unitTest.runtimeClasspath += files(dependenciesBuildDir) } classpath = sourceSets.unitTest.runtimeClasspath }
When this task is executed, it will need to know where to look for the compiled .class files. The rest of the task code serves this purpose. It instructs Gradle to look for current project's build folder plus all dependencies' build folders. Take note of the first line of task body. It's needed to tell Test class where its code has been compiled into, even though you don't see testClassesDir used anywhere else.
Switch to your console and type `gradle :your-project:unitTest`. Depends on test results, it will pass or fail your build!
Generate code coverage report with Gradle
Now it's important to be able to run tests, but you would have no idea if you manage to cover every execution path without a code coverage report. Luckily, unlike Java plugin, Jacoco plugin works with Android. All you need to do is add the plugin, tell your Test task where to generate jacoco execution data, and customize jacoco to generate a nice HTML report for you.
apply plugin: "jacoco" task unitTest(type: Test, dependsOn: assemble) { ... jacoco { append = false destinationFile = file("${buildDir}/jacoco/jacocoUnitTest.exec") } } task jacocoTestReport(type: JacocoReport, dependsOn: unitTest) { reports { xml.enabled false csv.enabled false html.destination "${buildDir}/jacocoHtml" } classDirectories = fileTree(dir: debugClassesDir) sourceDirectories = files(android.sourceSets.main.java.srcDirs) executionData = files(unitTest.jacoco.destinationFile) }
With everything in place now, you can make unit test a required step of your build (which you should), by having it run while Gradle checks for compilation errors.
andulkaphoto
dailybridgerton
titsay
kaledo-art
prguitarman
germansingergirl