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.
Instrumentation testing — basically, all the approaches on testing covered so far in this book — is wonderful, but it has one key problem: it is slow.
The problem stems largely from the fact that we are running our Android tests in Android. Android emulators are not speedy, and neither are devices, compared with developer machines, continuous integration servers, and the like.
Unit testing, in Android terms, is taking a subset of our tests out of Android and onto our development machine OS itself, running them just as we would plain Java tests in non-Android Java development. On the plus side, we now have much more machine power to run our tests, including the possibility of running tests in parallel across multiple CPU cores. However, whatever we are running for our development OS probably is not Android, and so attempts to use Android from our tests are doomed to failure… unless we mock Android.
In this chapter, we will explore more of why we might want to set up unit tests, the basics of setting up unit testing for plain old Java objects (POJOs), and how to use Mockito and Robolectric to mock certain things, notably Android itself.
This chapter assumes that you have read the preceding chapters on testing, particularly the one covering JUnit4.
Also, the examples in this chapter are based on the Retrofit example from the chapter on Internet access, so if you skipped the Retrofit material, you may wish to go back and review that section.
The preview of this section took that left turn at Albuquerque.
The preview of this section was last seen in the Bermuda Triangle.
The preview of this section was lost due to a rupture in the space-time continuum.
The preview of this section is sleeping in.
The preview of this section is presently indisposed.
The preview of this section was eaten by a grue.