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.
Test coverage is our way of determining whether or not we have adequately tested our code. Part of the work that has gone into the Android Gradle Plugin has been to make obtaining test coverage reports fairly easy, so ideally it is something that you can incorporate into your regular testing regimen.
In this chapter, we will explore the concept of test coverage in general, along with how to generate coverage reports for your Android instrumentation tests.
Understanding this chapter requires that you have read the chapter on instrumentation testing with JUnit.
We use tests to determine if our code works. More generally, we use tests as a way of quantifying the quality of our code. Code that fails the tests is of lower quality than is code that does not fail the tests.
Suppose we have some Java code that will result in divide-by-zero exception. We have two developers test that code. One developer writes tests and uncovers the exception. The other developer writes tests that bypasses the flawed code, and therefore does not uncover the exception. Here, the code quality is the same, but the test quality differs.
If the way we measure code quality is “does it pass the tests”, measuring test coverage asks “do the tests adequately test the code?”. In the preceding example, either:
What you want is to have a test suite that has 100% practical coverage.
The “practical” qualifier is because there are certain portions of our
code that may be impractical to test, because they depend upon certain
environmental factors that are different to arrange to happen
on demand (e.g.,
OutOfMemoryError). There, the objective is to have as
little code specifically dependent upon those factors, moving more of it
into code that we can test without requiring those conditions.
The preview of this section may contain nuts.
The preview of this section is in an invisible, microscopic font.