In this chapter, you will start with your first Android Testing. To guarantee quality of your Android application, you should follow the procedure as shown in Figure 16.
  • Design test specification
  • Develop test program
  • Execute test case on target device
  • Collect test result
Figure 16: Android application testing procedure

Design test specification This is the first step to test your application. In this step, you have to do:

  • Define target to be tested. In your Android application, there is many targets need to be tested such as UI, Activity, components, services. Define clearly target under test in your application will help you make powerful coverage test cases.
  • Plan the test types should be conducted (Unit test, Functional test, System test)
  • Design test cases with high coverage but minimize the number of test cases. The more code covered by your test, the higher early bug detection found on your application.

Write test program This section guides you how to write an Android test program using Android JUnit Test and Robotium. Assume that you have already developed an Android program name HelloAndroid. This program has some functions below:

  • Display a text “Hello world!” on screen
  • Display a message HelloAndroid when user press “Start” button
Figure 17: HelloAndroid Application

System Requirements

  • Android platform comes with pre-integrated JUnit 3.0 framework.
  • In order to create Android Test Project from Eclipse, your computer has installed:
  • Latest version Android Platform (currently Android 4.2.2)
  • Eclipse ADT plug-in (latest version is ADT  22.0.4)

You can download Eclipse IDE with built-in ADT (Android Developer Tools). It includes the essential Android SDK components and a version of the Eclipse IDE. Download at link http://developer.android.com/sdk/index.html. For the Robotium testing framework, you need to down Robotium library from Robotium webpage.

Coding Convention

  • Created into a separate parallel project
  • Named as the original project i.e. HelloAndroid plus the Tests suffix i.e.HelloAndroidTest
  • The field in Project creation steps:
  • Has the same Build Target as the original project
  • Application name can be empty
  • Package name use the original project’s package name appending the suffix .tests
  • Not to create an Activity as it’s not needed in most cases

Create Android Test Project

  • Click File→New →Other
  • Choose Android → Android Test Project  as figure below→ Choose Next
Figure 18: Create new Android test project

Write name of your test project. As naming convention, your test project should be named “HelloAndroidTest.”

Figure 19: Add test project name base on naming convention

Choose target application under test. In this case, this is HelloAndroid → click Finish

Figure 20: Choose target application under test

 Create Test Suites Base on your test specification, you started to create test suites for your test program. You can choose various Testing frame work as motioned in chapter 3. In this tutorial, I choose standard Android testing framework ActivityInstrumentationTestCase2. You have to add Robotium library file to a libs directory in your project folder in case you want to test with Robotium framework. (You create lib folder in your project folder). A test case defines the fixture to run multiple tests. To define a test case, you must follow the program structure below:

  • Implement a subclass of TestCase
  • Define instance variables that store the state of the fixture
  • Initialize the fixture state by overriding setUp()
  • Clean-up after a test by overriding tearDown().
Figure 21: Test program’s structure

Adding Test Cases

  • In the same package with TestSuite, we create TestCase classes
  • To test certain activity i.e. HelloAndroid, create a test case extent ActivityInstrumentationTestCase2
  • In this class, tester can get testing activity through getActivity() method
  • User freely create test for testing activity by creating method with name “test + original Method Name.”
  • In test method, tester can use Android JUnit function to compare the actual value and expected value. These methods are shown in Figure 22.
Figure 22: Example methods of Robotium and Android Testing Framework

These test suites above verified that Application GUI must display a text “Hello World!”, And contains a button name “Start.” For more detail about methods in Solo class, please refer here.  Run Testing After finishing writing your test program, you can start to run testing on application under test.  Follow steps below

  • Connect Android device to your PC (or start Emulator in case you don’t have real device)
  • In your IDE, right click →Run as→Android Unit Test
Figure 23: Running test program

Besides running test on IDE, you can run test on command line. In this test program, test package is com.example.helloandroid.test. In Linux terminal, you can use following command to run all tests in this package: $ ADB shell am instrument -w -e package com.example.helloandroid.test Get test result After finish executing, you can get test result output as shown in Figure 24. In this test program, there’re 4 test methods, corresponding 4 test cases, are executed.  In this case, all test cases are passed.

Figure 24: Test result output in case all test cases passed

In cases there’re test cases failed, the output is display and shows you which test cases failed.

Figure 25: Test result output in case all test cases failed

 Source code examples This article includes some Source Code examples which help you to understand the tutorial more clearly and quickly catch up the technical knowledge

Best practices

  • Application developers should create the test cases at the same time when they are writing the code
  • All test cases should be stored in version control-together with source code
  • Use continuous integration and run tests every time the code is changed
  • Avoid using emulators and rooted devices
  • Publish the test results to whole organization-real time

Emulator vs Device testing Emulator testing and device testing have some advantages and disadvantages,  see in Table 1. Table 1. Emulator Testing vs. Device Testing.

Best practices

  • Application developers should create the test cases at the same time when they are writing the code
  • All test cases should be stored in version control-together with source code
  • Use continuous integration and run tests every time the code is changed
  • Avoid using emulators and rooted devices
  • Publish the test results to whole organization-real time

Emulator vs Device testing Emulator testing and device testing have some advantages and disadvantages,  see in Table 1. Table 1. Emulator Testing vs. Device Testing.

Known the basic concepts of Android Application Testing

Best practices

  • Application developers should create the test cases at the same time when they are writing the code
  • All test cases should be stored in version control-together with source code
  • Use continuous integration and run tests every time the code is changed
  • Avoid using emulators and rooted devices
  • Publish the test results to whole organization-real time

Emulator vs Device testing Emulator testing and device testing have some advantages and disadvantages,  see in Table 1. Table 1. Emulator Testing vs. Device Testing.

Known various Automated Testing framework on Android and how to utilize them in your test program

Best practices

  • Application developers should create the test cases at the same time when they are writing the code
  • All test cases should be stored in version control-together with source code
  • Use continuous integration and run tests every time the code is changed
  • Avoid using emulators and rooted devices
  • Publish the test results to whole organization-real time

Emulator vs Device testing Emulator testing and device testing have some advantages and disadvantages,  see in Table 1. Table 1. Emulator Testing vs. Device Testing.

Could write your first test program and run it on emulators and real devices.

Best practices

  • Application developers should create the test cases at the same time when they are writing the code
  • All test cases should be stored in version control-together with source code
  • Use continuous integration and run tests every time the code is changed
  • Avoid using emulators and rooted devices
  • Publish the test results to whole organization-real time

Emulator vs Device testing Emulator testing and device testing have some advantages and disadvantages,  see in Table 1. Table 1. Emulator Testing vs. Device Testing.

Related posts: