DEV Community: Jérémy CROS

Robust UI tests with Espresso and Idling Resources

Jérémy CROS — Wed, 15 Jul 2020 12:07:51 +0000

A few years back, when I first dived in automated UI tests for Android using Espresso I very quickly noticed the framework lacked any reliable way to wait for an UI element to be displayed.

So I did what all good juniors would do, I added Thread.sleep() everywhere 😅

Fast forward to the present, new project, we want to add integration tests to the app and the Android team now has a recommended approach in Idling Resources.

A quick disclaimer on our setup first, since it heavily influenced how we chose to write the tests.
Early in the process, we decided against using mocks for the server. Our back office has a dev environnent with fixtures that mimic a fairly complex business system and tests users for authentication. It seemed more interesting from a testing point of view to directly access the server API but by doing so, we obviously introduced timing issues due to response time from the server.

This article is going to be our team's feedback of using espresso with Idling Resources and will assume you are familiar with writing Espresso tests.

The idling resource

The first thing to understand with idling resources is that there is going to be some impact in the "non-test" code.
I already see the eyebrows raising and I have to admit I had the same reaction too. Fortunately, there are ways to make that impact as minimal as possible.

The two classes we use are :

class SimpleCountingIdlingResource(
    private val resourceName: String
) : IdlingResource {

    private val counter = AtomicInteger(0)

    @Volatile
    private var resourceCallback:
        IdlingResource.ResourceCallback? = null

    override fun getName() = resourceName

    override fun isIdleNow() = counter.get() == 0

    override fun registerIdleTransitionCallback(
        resourceCallback: IdlingResource.ResourceCallback
    ) {
        this.resourceCallback = resourceCallback
    }

    fun increment() {
        counter.getAndIncrement()
    }

    fun decrement() {
        val counterVal = counter.decrementAndGet()
        if (counterVal == 0) {
            resourceCallback?.onTransitionToIdle()
        } else if (counterVal < 0) {
            throw IllegalStateException(
                "Counter has been corrupted!"
            )
        }
    }
}

and :

object TestIdlingResource {

    private const val RESOURCE = "GLOBAL"

    @JvmField
    val countingIdlingResource
        = SimpleCountingIdlingResource(RESOURCE)

    fun increment() {
        countingIdlingResource.increment()
    }

    fun decrement() {
        if (!countingIdlingResource.isIdleNow) {
            countingIdlingResource.decrement()
        }
    }
}

The second one serving as the entry point to notify Espresso the app is currently busy in a background process and should wait before carrying on with the test.

To make sure none of this is called in production, we used Gradle's product flavors. We already had them setup for other uses so we just had to add a dummy implementation of TestIdlingResource for non-dev flavors:

object TestIdlingResource {

    fun increment() {
        // no-op
    }

    fun decrement() {
        // no-op
    }
}

Updating your app code

Warning, here's the tricky part.
We need to use the idling resource at key moments in the app when it's busy.
I personally try to keep usage of them in fragment classes as to not hinder our unit tests suite.
To use the example of an authentication system, you could have something like:

fabValidate.setOnClickListener {
    TestIdlingResource.increment()
    viewModel.startLogin(user, pass)
}

and

private fun navigateToHomeAfterSuccessAuth() {
    TestIdlingResource.decrement()
    // Call to whatever abstraction
    // of the navigation you're using
}

It's hard to give clear advices here, you'll have to try, test and see what works best for you depending on your architecture.

Setting up the test

Registering the idling resource in the test is done as such:

private var idlingResource: IdlingResource? = null

@Before
fun setUp() {
    idlingResource = TestIdlingResource.countingIdlingResource
    IdlingRegistry.getInstance().register(idlingResource)
}

@After
fun tearDown() {
    idlingResource?.let {
        IdlingRegistry.getInstance().unregister(it)
    }
}

The espresso tests then become fairly straightforward.
Here, it properly waits the end of the authentication process before checking the home screen is displayed:

onView(withId(R.id.login)).perform(replaceText("user")))
onView(withId(R.id.pass)).perform(typeText("123456"))
onView(withId(R.id.fabValidate)).perform(click())
// No need to sleep the thread for seconds here!!!
onView(withId(R.id.home)).check(matches(isDisplayed()))

Hopefully, this article has shown you that you can write reliable UI tests with Espresso and TestIdlingResources 😎

As always, huge thanks to my team for review and feedback :)

Unit test a room migration on Android

Jérémy CROS — Wed, 10 Jun 2020 12:47:06 +0000

If you are using Room for your Android App database, chances are you've had to write a migration script at some point.

Something very simple like:

val MIGRATION_27_28 = object : Migration(27, 28) {
    override fun migrate(database: SupportSQLiteDatabase) {
        database.execSQL("ALTER TABLE User ADD COLUMN Company TEXT default 'Google'")
    }
}

The real beauty in those scripts though is that they are fully unit testable.
This article will show you step by step how to proceed.

The basic idea of how such a test will be structured is:

Create a database at the previous version
Insert the entity, complying to the previous version's schema
Run the migration script
Open the database, read the inserted entity and check the changes were properly applied

The first step is to add our test file. Because we're going to need to use an actual database on an emulator, it will be an instrumented unit test so let's start by creating our test class under the androidTest folder.

In our class, let's add an helper, part of the androidx.room.testing package as well as a constant for our database name.

private val testDatabase = "migration-test"

@get:Rule
val helper: MigrationTestHelper = MigrationTestHelper(
    InstrumentationRegistry.getInstrumentation(),
    MyRoomDatabase::class.java.canonicalName,
    FrameworkSQLiteOpenHelperFactory()
)

This helper will do all the migration work as well as well as validating the new database.
Except for the default value which we will have to test manually but we will come back to that later.

Now, a tricky part. If you remember point 2, we need to insert an entity at the previous version.
That means we cannot simply use our usual DAO classes to get the job done, the insertion would fail because we would miss our new field.
The only alternative is to build the object from scratch which is a bit cumbersome but the end result is worth it.

A good way to keep the code clean would be to have a function for that:

private fun buildUserToInsert_V27(): ContentValues {
    val user = ContentValues()
    user.put("id", "1")
    user.put("first_name", "john")
    user.put("last_name", "doe")
    user.put("age", "33")
    return user
}

I personally like to use an "Arrange / Act / Assert" way of organising my tests and the arrange part is now ready :)

// Arrange
val previousVersionUser = buildUserToInsert_V27()

helper.createDatabase(testDatabase, 27).apply {
    insert("User", SQLiteDatabase.CONFLICT_REPLACE, previousVersionUser)
    close()
}

Let's run our migration script:

// Act
helper.runMigrationsAndValidate(testDatabase, 28, true, MIGRATION_27_28)

All that's left is to check that our migrated user has the correct default company.
We need to open the migrated database. Again, nicely tucked in a function as it will be reused for all our migrations tests:

private fun getMigratedRoomDatabase(): MyRoomDatabase {
    return Room.databaseBuilder(
        InstrumentationRegistry.getInstrumentation().targetContext,
        MyRoomDatabase::class.java,
        testDatabase
    ).addMigrations(
        MIGRATION_27_28
    ).build().apply {
        openHelper.writableDatabase
        close()
    }
}

We now have access to our handy DAOs and the assert part is pretty straightforward:

// Assert
val migratedDatabase = getMigratedRoomDatabase()
val migratedUser = migratedDatabase.userDao().getById(1)
assertEquals("Google", migratedUser.company)

All done! :)
As you can see, there's unfortunately a fair bit of boilerplate to set up everything.
Good thing is, most of it is only done for the first test you'll write and can be reused for all subsequent tests.

The end result for our test class:

class MigrationsTest {
    private val testDatabase = "migration-test"

    @get:Rule
    val helper: MigrationTestHelper = MigrationTestHelper(
        InstrumentationRegistry.getInstrumentation(),
        MyRoomDatabase::class.java.canonicalName,
        FrameworkSQLiteOpenHelperFactory()
    )

    @Test
    @Throws(IOException::class)
    fun migrate27To28() {
        // Arrange
        val previousVersionUser = buildUserToInsert_V27()

        helper.createDatabase(testDatabase, 27).apply {
            insert("User", SQLiteDatabase.CONFLICT_REPLACE, previousVersionUser)
            close()
        }

        // Act
        helper.runMigrationsAndValidate(testDatabase, 28, true, MIGRATION_27_28)

        // Assert
        val migratedDatabase = getMigratedRoomDatabase()
        val migratedUser = migratedDatabase.userDao().getById(1)
        assertEquals("Google", migratedUser.company)
    }

    private fun getMigratedRoomDatabase(): MyRoomDatabase {
        return Room.databaseBuilder(
            InstrumentationRegistry.getInstrumentation().targetContext,
            MyRoomDatabase::class.java,
            testDatabase
        ).addMigrations(
            MIGRATION_27_28
        ).build().apply {
            openHelper.writableDatabase
            close()
        }
    }

    private fun buildUserToInsert_V27(): ContentValues {
        val user = ContentValues()
        user.put("id", "1")
        user.put("first_name", "john")
        user.put("last_name", "doe")
        user.put("age", "33")
        return user
    }
}

Leave me a question if anything is unclear and happy unit testing :)
And a big thanks to my teammates for reviewing this article!