Photo by Joseph James: Harmony in Sharing: A Tale of Two Horses and a Modest Meal

Creating Self-Contained UI Tests within Android Feature Modules: An Insight into Efficient Testing

Introduction

Software testing is an integral part of the development lifecycle. For Android applications, ensuring the user interface (UI) behaves as expected is crucial to offering a seamless user experience. UI testing can often become complex with the evolving requirements and feature additions in an app. This is where the concept of self-contained UI tests within feature modules comes in, bringing along benefits like isolation, modularity, and reliability.

In this article, we’ll take a deep dive into the setup and execution of self-contained UI tests within feature modules in Android, utilizing the Page Object Model (POM) design pattern and the Dagger 2 dependency injection framework.

What Are Self-Contained UI Tests?

In the world of software testing, self-contained UI tests are independent tests that are executed in isolation, without any dependencies on shared states, setups, or external modules. They are confined to a specific module and verify the functionality within that module alone. This approach aligns with the principle of single responsibility, keeping the tests clean and focused.

The Importance of Self-Contained UI Tests

So, why should you invest your efforts in setting up self-contained UI tests? Here are a few compelling reasons:

1. Isolation: Since each test is self-contained, the side-effects are minimized. An error in one test doesn’t cascade into others, making debugging easier and faster.
2. Modularity: The tests align well with the concept of feature modules. Each feature module focuses on one aspect of the application, and so do the tests, mirroring the modular approach.
3. Reliability: The tests are more reliable as they’re insulated from changes in other feature modules. Even if a change breaks something, it won’t affect the tests of another feature module.

The Power of Page Object Model (POM) and Dagger 2

The Page Object Model (POM) is a widely-adopted design pattern in automated testing. The idea is to create an object for each page or screen of the application. These objects then encapsulate the actions that a user can perform on those pages. This approach enhances the maintainability and readability of automated tests.

Dagger 2, on the other hand, is a popular dependency injection framework for Android and Java. It simplifies managing dependencies in our tests, allowing us to easily swap real implementations with fake or mock ones during testing.

Setting Up the UI Tests

Now, let’s get down to business and set up some self-contained UI tests within an Android feature module. For this example, we’ll imagine we have a Login feature module and we’ll write tests for the Login screen.

We’ll start by setting up a Page Object for the Login screen:

class LoginPage {
    private val usernameField = onView(withId(R.id.username))
    private val passwordField = onView(withId(R.id.password))
    private val loginButton = onView(withId(R.id.login))
    
    fun setUsername(username: String) {
        usernameField.perform(typeText(username))
    }
    
    fun setPassword(password: String) {
        passwordField.perform(typeText(password))
    }
    
    fun tapLogin() {
        loginButton.perform(click())
    }
}

With Dagger 2, we can create an ApplicationComponent inside our UI test module that will inject the required fake dependencies:

// TestAppComponent.kt
@Component(modules = [FakeNetworkModule::class, FakeDatabaseModule::class])
interface TestAppComponent {
    @Component.Factory
    interface Factory {
        fun create(@BindsInstance context: Context): TestAppComponent
    }
}

Finally, with the test environment set up, we can write our test:

@Test
fun whenValidCredentialsEntered_shouldNavigateToHomePage() {
    // Launch the activity
    val scenario = ActivityScenario.launch(LoginActivity::class.java)
    // Create a LoginPage object
    val loginPage = LoginPage()
    
    // Perform actions
    loginPage.setUsername("testUser")
    loginPage.setPassword("testPassword")
    loginPage.tapLogin()
    
    // Assertion
    onView(withId(R.id.home_page_layout))
    .check(matches(isDisplayed()))
}

Customizing the TestRunner and Gradle Configuration

In Android, the process of running tests is managed by a test runner. While Android provides a default test runner, AndroidJUnitRunner, you may need to customize it for specific requirements.

Creating a custom TestRunner allows us to control the environment in which the tests are executed. For instance, you can use the custom TestRunner to initialize a specific state before tests run or change the default test behavior.

Here’s how you can create a custom TestRunner:

class CustomTestRunner: AndroidJUnitRunner() {
    override fun newApplication(cl: ClassLoader?, className: String?, context: Context?): Application {
        // You can add some 
        return super.newApplication(cl, FakeApp::class.java.name, context)
    }
    
    override fun onStart() {
        // May be you can add your ideling resource related logic here.
    }
}

In this example, the newApplication method is overridden to return an instance of FakeApp instead of the real Application class. This FakeApp could then be set up with the TestAppComponent mentioned earlier, allowing the injection of fake implementations for all tests.

After creating our custom TestRunner, we need to instruct our Gradle build system to use it for executing tests. This is done by adding the fully qualified name of our TestRunner in the build.gradle file:

android {
    defaultConfig {
        testInstrumentationRunner "com.example.myapp.CustomTestRunner"
    }
}

In this case, replace com.example.myapp.CustomTestRunner with the fully qualified name of your custom TestRunner.

This Gradle configuration will ensure that whenever the tests are run, either locally or in the CI environment, they use the CustomTestRunner which has been set up to use the FakeApp, thus ensuring the injection of fake dependencies.

Conclusion

Adopting the approach of self-contained UI tests within feature modules and adding customizations like a TestRunner can provide you with a highly robust, maintainable, and scalable test suite. By combining this with selective test execution in your CI pipeline, you can achieve faster development cycles, higher productivity, and more reliable software.

Embrace the power of targeted, efficient testing and enjoy the process of building outstanding Android apps!

Happy Coding! 🚀