Unit 6: Introduction to Other Mobile Testing Tools

I. Orientation: Mobile Test-Automation Tools

Mobile test automation uses software to execute repeatable actions on mobile applications, verify observable results, and report failures. Tools differ mainly in their supported platforms, application types, execution architecture, synchronization model, and level of programming required.

• Primary objective: Automated tests check whether an application behaves as expected across builds, devices, operating-system versions, screen sizes, and user states.
• Application types:
  • Native applications: Built for a specific platform, such as Android applications written in Kotlin or Java.
  • Mobile web applications: Websites executed in a mobile browser.
  • Hybrid applications: Native containers that display some content through web views.
• Testing levels:
  • UI testing: Operates buttons, text fields, lists, dialogs, and other visible controls.
  • Functional testing: Verifies workflows such as authentication, search, checkout, or data entry.
  • Regression testing: Re-executes established tests after code changes.
• Element identification: Tools locate controls through resource IDs, visible text, accessibility labels, class names, XPath expressions, or platform-specific matchers.
• Execution architecture: A test may run inside the application process, through an instrumentation process, or through an external automation server.
• Assertions: A test normally follows the pattern arrange, act, assert: establish initial conditions, perform an action, and compare the result with an expected value.
• Automation requirements: Reliable tests need isolated test data, deterministic setup, explicit assertions, suitable synchronization, and cleanup after execution.
• Tool-selection factors: Platform support, source-code access, supported application type, team skills, CI integration, maintenance status, execution speed, and reporting requirements determine which tool is appropriate.

II. Katalon Studio: Integrated Low-Code Automation

A. Basics of Katalon Studio

Katalon Studio is an integrated test-automation environment that supports mobile, web, API, and desktop testing through record-and-playback facilities, reusable keywords, and scripted tests.

• Mobile foundation: Katalon delegates mobile-device interaction to Appium, while providing an IDE, object repository, keyword APIs, reporting, and execution configuration around it.
• Platform support: Mobile projects can test Android and iOS applications, subject to the underlying Appium, device, host-system, and driver requirements.
• Testing modes:
  1. Manual view: Test steps are assembled from keywords with limited coding.
  2. Script view: Tests are edited as Groovy-based scripts and may use Java libraries.
• Object Repository: Located elements are stored as reusable test objects containing selectors such as id, class, accessibility identifier, or XPath.
• Mobile utilities:
  • Mobile Object Spy: Inspects a connected application and captures element properties.
  • Mobile Recorder: Records user actions and converts them into executable keyword steps.
• Common keywords: startApplication, tap, setText, verifyElementVisible, swipe, and closeApplication represent typical mobile operations.
• Execution setup: Testing usually requires a configured Android SDK or iOS environment, compatible Appium components, an emulator or physical device, and the application package.
• Concrete test flow:

Mobile.startApplication('/apps/shop.apk', false)
Mobile.tap(findTestObject('Login/username'), 10)
Mobile.setText(findTestObject('Login/username'), 'student', 10)
Mobile.tap(findTestObject('Login/signIn'), 10)
Mobile.verifyElementVisible(findTestObject('Home/title'), 10)
Mobile.closeApplication()

• Parameter meaning: The path identifies the application package; false controls whether application data is reset according to the keyword’s API behavior; 10 is the timeout in seconds.
• Data-driven testing: Test cases can receive values from internal data files, spreadsheets, CSV files, databases, or profiles, allowing one login flow to run with several credential sets.
• Reusable logic: Custom keywords and called test cases reduce duplication across workflows.

B. Applications and Limitations

Katalon is most useful when a team needs broad automation capabilities and a guided interface, but its convenience introduces additional tooling and configuration layers.

• Applications: It supports regression suites, smoke tests, cross-device flows, reusable business keywords, scheduled execution, and CI-driven test runs.
• Reporting: Execution logs, screenshots, step results, and integrations help teams investigate failed cases.
• Advantages: Recorder tools and built-in keywords shorten initial development, while script mode permits more advanced customization.
• Limitations: Recorded tests may create brittle selectors, complex failures may require Appium knowledge, and some collaboration or enterprise capabilities depend on product licensing.
• Maintenance concern: Stable resource IDs and reusable test objects are preferable to long XPath expressions because UI hierarchy changes can invalidate position-based selectors.

III. Espresso: Native Android UI Testing

A. Basics of Espresso

Espresso is Google’s Android UI-testing framework for writing concise instrumentation tests that interact with an application and verify its visible state.

• Core principle: Espresso runs with Android instrumentation and synchronizes test operations with the application’s main UI thread, reducing arbitrary delays.
• Basic model:
  • View matcher: Finds a view, such as withId(R.id.login_button).
  • View action: Performs an operation, such as click() or typeText().
  • View assertion: Checks a condition, such as matches(isDisplayed()).
• Canonical syntax:

onView(withId(R.id.username))
    .perform(typeText("student"), closeSoftKeyboard())

onView(withId(R.id.login_button))
    .perform(click())

onView(withText("Welcome"))
    .check(matches(isDisplayed()))

• Concrete anchors: R.id.username and R.id.login_button are compiled Android resource identifiers; "Welcome" is matched against displayed text.
• Synchronization: Espresso waits for the main message queue and registered asynchronous resources to become idle before continuing.
• Idling resources: IdlingResource informs Espresso about background work not automatically observable, such as a network request managed outside standard UI scheduling.
• Test location: Instrumented tests usually reside under src/androidTest, separate from local JVM tests in src/test.
• Test runner: Android projects commonly execute Espresso tests with AndroidJUnitRunner on an emulator or physical Android device.
• Related capabilities: Espresso-Intents can verify or stub intents, while RecyclerView test support enables actions on list items.

B. Applications and Limitations

Espresso is appropriate for fast, source-aware Android UI testing, especially when tests are maintained alongside application code.

• Applications: It verifies activities, fragments, forms, navigation, dialogs, lists, validation messages, and interactions between Android views.
• Advantages: Tight Android integration, readable matcher-action-assertion syntax, and automatic synchronization make tests generally faster and more stable than externally driven UI tests.
• Limitations: It is Android-specific, normally requires access to the application project, and does not provide one test implementation for both Android and iOS.
• Synchronization boundary: Espresso cannot automatically infer every custom background operation; unregistered asynchronous work can still cause flaky assertions.
• Design implication: Unique resource IDs and accessible UI structures make tests clearer than selectors based only on text or hierarchy position.

IV. Robotium: Android Black-Box and Gray-Box Automation

A. Basics of Robotium

Robotium is an Android UI-testing framework built around the Solo API, designed to automate native and some hybrid application interactions through Android instrumentation.

• Central component: A Solo object provides high-level operations such as clicking text, entering values, scrolling, waiting for activities, and checking view presence.
• Testing styles:
  1. Gray-box testing: Tests are built with the application source and can use resource IDs or application classes.
  2. Black-box testing: Tests target a compiled APK with less direct knowledge of internal implementation.
• Typical structure:

private Solo solo;

@Before
public void setUp() {
    solo = new Solo(InstrumentationRegistry.getInstrumentation());
}

@Test
public void loginDisplaysHome() {
    solo.enterText(0, "student");
    solo.clickOnText("Sign in");
    assertTrue(solo.waitForText("Home"));
}

• Concrete behavior: enterText(0, ...) targets the first matching editable field, while clickOnText("Sign in") searches for visible text.
• Instrumentation: Robotium tests execute through Android’s instrumentation facilities and interact with activities and views.
• Waiting support: Methods such as waitForText and waitForActivity are preferable to fixed sleeps because they wait for a specific observable condition.
• Coverage: Robotium can navigate multiple activities and perform common gestures and view interactions using concise commands.

B. Applications and Limitations

Robotium is mainly significant as an earlier simplification of Android UI automation, but it is now unsuitable for most new projects.

• Applications: It has been used for functional, system, acceptance, and regression testing of Android applications.
• Advantages: The Solo API reduces low-level instrumentation code and can automate workflows spanning several activities.
• Limitations: Android-only support, dependence on older testing patterns, limited modern ecosystem integration, and weak cross-platform capability restrict its present value.
• Maintenance status: Robotium is no longer actively maintained, so compatibility with current Android tooling and UI frameworks cannot be assumed.
• Selector risk: Index-based operations such as enterText(0, ...) are fragile because adding another field can change the target; stable resource IDs are safer.

V. Selendroid: WebDriver-Based Android Automation

A. Basics of Selendroid

Selendroid was an Android automation framework that exposed native and hybrid application elements through a Selenium WebDriver-compatible client-server architecture.

• Architecture: A test client sent WebDriver commands to a Selendroid server, which translated them into actions on an Android application or browser.
• Application support: It targeted native Android applications, hybrid applications containing web views, and mobile web content.
• WebDriver model: Tests created a driver session, located elements, performed actions, and evaluated results through familiar Selenium APIs.
• Illustrative flow:

WebDriver driver = new SelendroidDriver(capabilities);
driver.findElement(By.id("username")).sendKeys("student");
driver.findElement(By.id("sign_in")).click();
assertTrue(driver.findElement(By.id("home_title")).isDisplayed());
driver.quit();

• Concrete anchors: capabilities described the target application and device session; By.id(...) located elements; quit() released the server session.
• Hybrid context: WebDriver-style access made Selendroid attractive to testers already familiar with Selenium concepts and browser automation.
• Parallel potential: Its server-based design permitted automation sessions to be distributed across multiple Android devices when infrastructure was configured accordingly.
• No application-code requirement: Selendroid could automate an application without requiring testers to modify its source code, although APK preparation and framework compatibility still mattered.

B. Applications and Limitations

Selendroid is historically important for bringing Selenium-style automation to Android, but it has been superseded by maintained alternatives.

• Applications: It was used for Android functional testing, mobile web testing, hybrid-app validation, and Selenium-oriented test suites.
• Advantages: WebDriver familiarity, multiple locator strategies, external test execution, and native-to-web testing concepts lowered the learning barrier for Selenium users.
• Limitations: The framework is no longer actively maintained and does not reliably support modern Android versions, current application architectures, or contemporary automation requirements.
• Successor relationship: Appium became the practical cross-platform WebDriver-based choice because it supports modern Android and iOS automation through maintained platform drivers.
• Current use: Selendroid should generally be studied for architectural and historical understanding; new automation projects should select an actively maintained framework such as Appium or Espresso.