The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.
Presumably, you will want to test your code, beyond just playing around with it yourself by hand. Android offers several means of testing your app, covered in this next series of chapters.
The first Android SDK testing solution we will examine is the JUnit test framework.
This is a standard Java unit testing framework. Originally, Android
itself “baked in” a copy of JUnit3. This has since been deprecated,
and modern Android testing is done with a separate copy of JUnit4,
in the form of a
In this chapter, we will review how to apply the
to run JUnit4 tests for our Android apps.
Understanding this chapter requires that you have read the chapter on Gradle dependencies.
This chapter also assumes you have some familiarity with JUnit, though you certainly do not need to be an expert. You can learn more about JUnit at the JUnit site, from various books, and from the JUnit Yahoo forum.
There are two places in Android app development where we use JUnit4:
instrumentation tests and unit tests. Both serve the same objective:
confirm that our code runs as expected. What differs in where the
code lives (
test sourcesets) and where the
code runs (inside of Android or on your development machine directly).
The following sections outline the differences between the two, though there is a separate chapter dedicated to unit testing, with the bulk of this chapter focused on instrumentation testing.
One common problem with testing is determining where the test code should reside, relative to the production code being tested. Ideally, these are not intermingled, as that would increase the odds that you might accidentally ship the testing code as part of your production app — at best, this increases your APK size; at worst, it could open up security flaws.
With Gradle-based projects, including those created for Android Studio,
we have a dedicated sourceset for our instrumentation tests, named
the code for those tests would reside.
As with any sourceset,
androidTest can have Java code, resources,
etc. It does not
AndroidManifest.xml file, though, as that will be auto-generated.
Unit tests, by contrast, will go in a
Ordinarily, each code base (e.g., project) is packaged in its own APK and is executed in its own process.
In the case of instrumentation tests, your test code and your production code are combined into a single process in a single copy of the virtual machine.
This will allow your JUnit test methods to access objects from your production code, such as your activities and their widgets.
However, this does limit instrumentation testing to be run from a developer’s computer. You cannot package JUnit tests to be initiated from the device itself, except perhaps on rooted devices.
Unit tests, on the other hand, bypass Android and run straight on your development machine. As a result, they cannot use much of the Android SDK, and so these tests are limited in terms of what they can test. However, they will run much more quickly, and so it may be worthwhile to set up a subset of your tests as unit tests.
The preview of this section is in the process of being translated from its native Klingon.
The preview of this section was last seen in the Bermuda Triangle.
The preview of this section is in an invisible, microscopic font.
The preview of this section is out seeking fame and fortune as the Dread Pirate Roberts.