Hello ladies and gentlemen!! Hope you are doing well. Today we are going to have an overture on activity testing. Activities also have a complex lifecycle which need to be managed. Let us get a short introduction to activity testing.

13.8.1 Introduction to Activity testing

Activities life cycle is complex because it is based on callback methods. These callback methods are managed by instrumentation. Events are sent to user interface via instrumentation. API base class is InstrumentationTestCase. This class is responsible  for activity testing. It provides instrumentation to test the subclasses which we use for activities. It provides the following functionalities:

• With instrumentation we can control the lifecycle. Activity can be started, paused and stopped.
• This allows to create mock system objects which can be used to run the activity under test. With this we can control the test environment as it can be isolated from rest of the test environment.
• This can be used to send keystrokes or touch events directly to the UI of the activity under test.

You must be thinking about the components which need to be tested. These things are to be tested:

• We need to test whether activity correctly responds to user interface or not.
• We need to test whether activities handles lifecycle events appropriately or not. Events are the actions from system or from the user which are triggered by callback methods like onCreate(), etc.
• We need to test whether activity correctly handles the intents listed in the intent filter. These intent filters are specified in the manifest.
• Activities are to be tested in terms o runtime configuration. We need to check whether application corresponds with respect to changes in device’s configuration.
• We need to make sure that applications should run perfectly oin different screen sizes before publishing into market.

The two main subclasses under testing framework are as follows:

• When we use normal infrastructure the ActivityInstrumentationTestCase2 test case class is designed to do functional testing of one or more constituent Activities of an application.  It allows us to send mock Intents to the activity. We can use it to test an activity that responds to multiple types of intents.  It can be also be used to test an activity that expects a certain type of data in the intent, 
•  ActivityUnitTestCase test case class tests a single activity in isolation. We can inject a mock Context or Application or both instead. We can also use it to do unit testing of methods that do not interact with Android.

Applications’ UI thread is the one where activities of an application run. We can invoke methods against the UI of the application under test when we run tests against application. We can annotate the thread with @UIThreadTest when we run an entire test method on UI thread. We have to keep in mind that methods which do not interact with the UI are not allowed.

Congratulations guysJ!! We are done with this section. See you in the next section with something new and informational. Till then keep practicing. Happy App Developing!!