The functional testing on Android

Testing it the most of the main item on development. The mistake, which was not detected in time, can lead to collapse the mobile application. As the clients want ‘all and now’, and one mistake leads to low estimates and poor reviews from consumers on start.  

Therefore, our developers are checking every mobile application very assiduously, independently the android app or ios app.

At first, let’s consider the Unit Testing. It is the process of the code typing, for the check the behavior and functionality of your system.

Below is an example of test conditions:

  1. Test dependencies:

   testImplementation ‘junit:junit:4.12’

   testImplementation “org.robolectric:robolectric:3.3.2”

   testImplementation ‘org.robolectric:shadows-support-v4:3.0’

   testImplementation “org.mockito:mockito-core:1.10.19”

   testImplementation “org.powermock:powermock-module-junit4:1.6.5”

   testImplementation “org.powermock:powermock-module-junit4-rule:1.6.5”

   testImplementation “org.powermock:powermock-api-mockito:1.6.5”

   testImplementation “org.powermock:powermock-classloading-xstream:1.6.5”

We have the dependence from junit, robolectric, mockito, and powermock. Let’s consider them in detail:

Junit – it’s the library for unit testing, related to testing java applications. Used for unit testing, which allows you to check for certain modules of the source code of the program. The advantage of this approach is to isolate a single module from others. At the same time, the purpose of this method allows the programmer to make sure that the module, by itself, is able to work correctly.

Robolectric – it’s the library for unit testing too, what using for classes, which needest in Context.

Mockito – it’s the main of the library for creating the mock, that is objects that replacing real objects and providing their own behavior. For example: if we testing the Fragment, and in it, there is a link to the database, then the database needs to mock, and each request to change the behavior:

DB db = mock(DB.class);

Mockito.when(db.getAccount()).thenReturn(->> return some result).

Powermock – it’s like Mockito, but can work with static-methods, final classes, protected and also private fields and etc. Serves as an additional tool, for example for mockStatic.

2. Base class for testing:

@RunWith(RobolectricTestRunner.class)

@Config(constants = BuildConfig.class)

@PowerMockIgnore({“org.mockito.*”, “org.robolectric.*”, “android.*”})

@SuppressStaticInitializationFor(“io.realm.internal.Util”)

@PrepareForTest({Realm.class, RealmLog.class})

public abstract class RealmBaseTest {

   @Rule

   public PowerMockRule powerMockRule = new PowerMockRule();

   protected Realm mMockRealm;

   @Before

   public void initRealm() throws Exception {

       mockStatic(RealmLog.class);

       mockStatic(Realm.class);

       mMockRealm = PowerMockito.mock(Realm.class);

       when(Realm.getDefaultInstance()).thenReturn(mMockRealm);

   }

}

 

This class is started by RobolectricTestRunner, but also, supported the PowerMock.

In initRealm method, the Realm object is mock, and the behavior of the method is specified Realm.getDefaultInstance().

In this case Realm.getDefaultInstance() will return our MockRealm variable.

3. Example the when condition to get the argument as the return value:

when(mockRealm.copyToRealmOrUpdate(any(RealmModel.class)))

              .thenAnswer(invocationOnMock -> invocationOnMock.getArguments()[0]);

       when(mockRealm.copyFromRealm(any(RealmModel.class)))

              .thenAnswer(invocationOnMock -> invocationOnMock.getArguments()[0]);

4. An example of using verify, to track whether the executeTransaction method was called exactly once:

Mockito.verify(mockRealm,

Mockito.times(1)).executeTransaction(Mockito.any(Realm.Transaction.class));

5. An example for mock RealmQuery and RealmResult methods:

@SuppressWarnings(“unchecked”)

   protected  <T extends RealmObject> RealmQuery<T> mockRealmQuery() {

       return mock(RealmQuery.class);

   }

   @SuppressWarnings(“unchecked”)

   protected <T extends RealmObject> RealmResults<T> mockRealmResult() {

       return mock(RealmResults.class);

   }

6. An example mock for the createObject method:

when(mockRealm.createObject(Movement.class, “testMovement”)).thenReturn(testMovement);

when(mockRealm.createObject(MovementPreset.class, “testMovement”)).thenReturn(testMovementPreset);

7. Example mock for the query realm.where(Movement.class).equalsTo(“movementName”, “testMovement”).findFirst();   

RealmQuery<Movement> mockMovementQuery = mockRealmQuery();

  when(mockRealm.where(Movement.class)).thenReturn(mockMovementQuery);

  when(mockMovementQuery.equalTo(“movementName”, “testMovement”)).thenReturn(mockMovementQuery);

  when(mockMovementQuery.findFirst()).thenReturn(testMovement);   

What about UI testing. User Interface Testing – it’s the test user graphic interface, which assumes to check the site for compliance with the requirements for a graphical interface: whether it looks professional, whether it is made in the same style and etc. For Ui testing, we use the Espresso framework. This is so clever framework, that correctly checks all the elements. In this, it can wait some time, while a certain condition is satisfied – what is very convenient because the elements do not always appear instantly on the screen. Espresso allows you to perform actions on UI-elements (buttons, input fields and other) and to check the various conditions for these UI elements (correctness of the text, enabled / disabled and other). In the basic view, the Espresso framework allows you to find the View on the screen, to perform with them some actions and verify the fulfillment of the conditions.

Our testers know a lot about quality testing. So we guarantee the quality and reliability of your product.

Leave a Reply

Your email address will not be published. Required fields are marked *