Test Design of native app automation

4 min readNov 18, 2021

Test Objective

To run all unit and automated tests in CI as soon as any developer or any tester commits in any GitHub branch.

Test Approach

Shift-Left

Cost of a bug detection at a later stage and fixing it, is very expensive. Earliest bug detection is ideal and helpful to everyone in team and business. Hence, the concept of “Shift-Left” approach has been followed in the industry now and is widely used and supported.

Shift-left by nature prevent occurrence of bug at development stage itself, thus avoiding chances of bug-detection at a later stage.

In-sprint automation

While TDD is ideally aspired, it’s still desired to adopt and implement in-sprint automation by the dev and testing team that complements TDD practices. Remember that this must be followed in both android and iOS platforms.

Standard Test Practices

AAA (Arrange, Act, Assert)

Each page object class shall follow AAA pattern religiously.
Functions in UI Tests can have multiple assertions.
Having logics is acceptable in page object class if it reduces lines of code and optimizes the test code further.

F-POM (Fluent Page Object Model)

Each page object class shall contribute to method chaining.
Contributing to simpler and readable test scripts.

Screenplay

Replicates End User’s journey in large and medium tests.
Apple and Google, both encourage Large & Medium tests in UI-Test.

Red, Green, Refactor

Do not write the test to pass always.
Make sure the test fails when something is wrong.
First write the test to fail, then check if the test passes and then refactor the test.

Clean Test Code

KISS (Keep It Short and Simple)

Keep all test code to be simple & readable.
Have multiple small functions in page object class when possible.

2. DRY (Don’t Repeat Yourself)

If any data or line of code is found repeated anywhere during scripting, add it in well-organized reusable components.

3. Test Code Reuse

All generic reusable components should be organized and placed in protocols.

4. Yagni (You aren’t gonna need it)

Implement the simplest approach that works best.
Don’t commit/push any line of test code if is unused.

Distributed Parallel Testing in CI

Running tests in CI across multiple BrowserStack devices.
Can be enabled in CI for develop/merging branches to add value.
Can be disabled for dev and test branches.

Components of iOS UI Test Framework

Test Plan — for easier and flexible CI test runs
Elements — for easy maintainability and avoid duplication
Services/Objects — for placing all page object functions
Protocols/Extensions — for reusing only what is needed
Tests — for placing all tests for running
Mock Server — to run tests reliably & faster
Common

👉 Accessibility Identifiers — to avoid flaky tests

👉 Test Base — for parent test class instructions

👉 Test Data — for avoiding test data duplication

Sample Projects for understanding:

IOS — XCUITest

Components of Espresso Android Test Framework

Services/Objects — for placing all page object functions
Tests — for placing all tests for running
Mock Server
Common
Test Base — for parent test class instructions
Test Data — for avoiding test data duplication

Test Result Analysis

IOS

Is Inbuilt and generated by XCode on every test run automatically.
Generates Test Result Bundle -> XCResult file after every test run.
Contains all information such as: Build logs, Test Result, code coverage results, test attachments (screenshots)

Android

Jacoco
Junit Report

Library/Framework Testing

Android Studio in Java using Junit.
XCode in Swift and Obj C languages using XCTest.

Visual Testing

Implement the following in new test Schemes & folders for any different type of testing.

Accessibility Testing

Localization Testing

To-do in XCode and Android Studio in the above test projects itself, may be in a different scheme if required.