Android UI Automation: Part 1, Building Trust

Developer-driven automated testing is vital to the ongoing health and quality of a codebase. It does, however, come with a noticeable cost. This is especially true of UI testing — an area often avoided by even the most test-friendly of developers. In this two-part blog post, we explore how the Slack Android team made authoring and maintaining…

Slack logo
Slack
•
Valera Zakharov
•13 min read•advanced•
--
•View Original
ChefMVCMVPMVVMReactSQLite

Overview

This article discusses the integration of UI testing into the Android development workflow at Slack, emphasizing the importance of developer-driven automated testing for maintaining code quality. It outlines strategies for making UI tests stable and effective, while also addressing common developer concerns about UI testing.

What You'll Learn

1

How to integrate UI testing into the Android development workflow

2

Why maintaining a stable UI test suite is crucial for developer confidence

3

How to create targeted and hermetic UI tests to reduce flakiness

Prerequisites & Requirements

  • Understanding of automated testing principles
  • Familiarity with Android development tools and frameworks(optional)

Key Questions Answered

What are the benefits of authoring UI tests as a developer?
Authoring UI tests enables developers to move quickly and confidently, reducing the risk of introducing bugs during feature development. It also encourages better code design by promoting modularity and maintainability, ultimately leading to a healthier codebase.
How can developers ensure the stability of their UI tests?
To ensure stability, developers should focus on writing targeted tests that only validate the necessary functionality and maintain control over the test state. This approach minimizes dependencies on external factors that can lead to flaky tests.
What strategies did Slack implement to improve UI testing?
Slack's strategy involved reducing the need for extensive UI testing by employing targeted and hermetic tests. This included using dependency injection to manage application state and ensuring tests are isolated from non-deterministic factors.
What are the common concerns developers have about UI testing?
Common concerns include the perceived instability of UI tests, the time investment required to maintain them, and the tendency to defer testing until later in the development process. Addressing these concerns is crucial for fostering a test-friendly culture.

Key Statistics & Figures

Percentage of developers who write UI tests
37%
In a survey, 37% of developers reported not adding UI tests for features they worked on, highlighting a significant gap in testing practices.

Technologies & Tools

Dependency Injection
Dagger
Used to manage application state and facilitate testing by allowing the injection of mock objects.
Testing Framework
Mockito
Utilized for creating test doubles to simulate application behavior during testing.

Key Actionable Insights

1
Developers should start integrating UI tests into their workflow immediately to avoid the pitfalls of deferred testing.
Delaying testing can lead to increased technical debt and a lack of confidence in code changes, especially as project complexity grows.
2
Implement targeted UI tests that focus on specific functionalities rather than navigating through the entire application.
This approach reduces test execution time and minimizes the likelihood of failures due to unrelated code paths.
3
Utilize dependency injection frameworks like Dagger to manage application state in tests effectively.
By controlling the application state, developers can create more reliable tests that do not depend on the full application lifecycle.

Common Pitfalls

1
Relying on sleep calls or similar mechanisms in tests can lead to flaky UI tests.
This practice often results in race conditions and unpredictable test outcomes. Instead, developers should use synchronization methods like Espresso's IdlingResource to manage background operations.

Related Concepts

Automated Testing
Dependency Injection
Test-driven Development