13.9 Android Service Testing, Content Provider Testing and accessibility testing

Hello ladies and gentlemenJ!! Today we are going to introduce ourselves to some important fundamentals about testing framework. These concepts are explained as follows.

13.9.1 Introduction to Service Testing

Service is an important phenomenon in the field of testing. So it is a fundamental part of testing framework. We can run Service objects in isolation and provides mock objects.  ServiceTestCase is the test case class for Service objects. We can test Service object without instrumentation because Service considers itself as a separate client. Services also have a lifecycle. Lifecycle methods which start our Service do not normally set a global variable which indicates they are successful or not.  These methods like onCreate() or onStartCommand().

            ServiceTestCase extends the JUnit TestCase class. The methods used for inheritance are methods which are used for testing application permissions and for controlling the application and Service undergoing the test. It is possible as it facilitates mock application and Context objects which would isolate our test from the rest of the system. The call to ServiceTestCase.startService() or ServiceTestCase.bindService() allows us to set up our test environment. This includes particularly our mock objects before the Service is started. Mock objects isolate the test environment from rest of the system. ServiceTestCase creates its own internal instance and inject them into the Service. We do not provide our own instances before the service starts itself.

Following components need to be tested when we talk about service testing:

  • We need to be sure of the fact that onCreate() is called. It should be called in response to Context.bindService(). In return we need to be sure that onDestroy() is called in response to Context.stopService(), Context.unbindService(), stopSelfResult() or stopSelf().
  • We need to test that service correctly handles multiple calls from Context.startService()
  • Business logic constitutes checking for invalid values, financial and arithmetic calculations, etc. We need to test business logic which our service is going to implement.

13.9.2 Introduction to Content Provider Testing

Content Providers stores and retrieves data so that it can be accessible via all applications. This is a key part of Android API. Content Providers are viewed as data APIs that provide tables of data. And they include internals hidden from view. Content Providers may include public constants. We have to write tests which are based only on the providers’ public members.

             ProviderTestCase2 is the base test case class for content providers. It allows us to test our content providers in an isolated environment. Mock objects such as IsolatedContext and MockContentResolver can provide an isolated test environment.

Following components are to be taken care of when we talk about content provider testing:

  • We should always test with a resolver object using the appropriate URI as it is going to ensure that we are testing the provider using the same interaction that a regular application is going to use.
  • Usually we would intent our provider to be public so that is available to all over the system. We have to test with constants that our provider is going to expose publicly. We have to test all the URIs which is provided by this provider. It may offer several URIs where each URI is going to refer a different aspect of the data. A well designed provider should throw IllegalArgumentException for invalid URIs
  • In general providers offer six access methods: query, insert, delete, update, getType, and onCreate() so we need to test whether provider is capable of facilitating all these methods efficiently.
  • Similar to Service testing, business logic need to be tested and it is an important part.

            ProviderTestCase2 extends AndroidTestCase thus it provides the JUnit testing framework as well as Android-specific methods which is required for testing application permissions. The initialization is done in the constructor for ProviderTestCase2 and its initialization is important as it creates isolated test environment. This constructor creates an IsolatedContext object which allows file and database operations. The constructor in turn also creates a MockContentResolver which os going to be resolver for test. File and database operations takes place in directory which is local to device. Finally, constructor creates an instance of the provider under test.

13.9.3 Introduction to Accessibility Testing

Application should be accessible to users with different capabilities. The goal should be to set up and use application without the need of any noticeable assistance. Another goal should be to include a task workflows in the application which can be easily navigated using directional controls and provide clear. It should also provide appropriate feedback.

Following components are to be taken care of when we talk about accessibility testing:

  • We should verify that the application can be operated without the use of a touch screen. We should try to use only directional controls for accomplishment of primary tasks in the application
  • We need to verify whether user interface controls which provides some graphical or textual information. We need to allow user action which have clear and accurate audio descriptions and controls are focused.
  • We need to verify that user interface controls should provide graphical or textual information. It should allow user action which have proper audio descriptions when explore by touch is enabled.
  • We need to be sure that controls which user can select or take an action must be of minimum 48 dp in length and width. It is approximately 9mm.
  • We have to verify that gestures which are app-specific controls should be operable when talk back is enabled. Otherwise, alternatives should be provided.
  • As a good developer and tester we should support users who are deaf or hard of hearing with an audio feedback.

We should verify that closely related controls do not just repeat the same audio prompt. We should also verify that closely related controls provide an appropriate level of audio information which enables users to understand and act on a screen element. We should also review the list of special cases for accessibility development. We need to test our application for the cases which apply. The buttons or other input controls which changes function due to application context or workflow must provide audio prompts which corresponds to current function. If the application provides video playback then we need to verify that it supports valued customers who are deaf or hard of hearing.  

Congratulations guysJ!! We are done with this section. See you in next section with some more fundamental concepts. Till then keep practicing. Happy App DevelopingJ!!