DEV Community: Roman Chugunov

Practical tips for code reviews in large teams

Roman Chugunov — Sat, 21 Oct 2023 19:57:23 +0000

Improving the code review process is crucial for development teams aiming to maintain and elevate their efficiency and code quality. A growing list of pending pull requests (PRs) can be overwhelming and even demoralizing. By refining the review process, teams can ensure a balanced distribution of PRs, preventing certain team members from becoming inundated while others remain idle. Striving for equality in time spent on PRs helps in fostering a cohesive and harmonious team environment. Furthermore, adhering to a standard that aims for a review time of up to just one business day guarantees swift feedback and fosters a dynamic, responsive development cycle. Lastly, the essence of the improvement drive is to enhance the quality of PRs, ensuring they are optimally sized, adequately prepared, and comprehensive, which in turn streamlines the entire development process.

How to measure Code Review effectiveness

To gauge the efficacy of code review processes, it's essential to focus on team performance rather than individual contributions. Key metrics include the duration a pull request (PR) remains under review and the time a PR is in the review phase relative to its total lines of code. Monitoring the number of PRs that remain open and the volume of code within each PR can further provide insights into the efficiency of the review process.

Measure the effectiveness of the team rather than effectiveness of certain people
Measure time for how long PR stays in review state.
Measure time for how long a PR stays in review state divided by lines of code.
Number of PRs in open state.
Lines of code in PR

This can be achieved by introducing tools for collecting information about PRs. If you use Github there is a github action issue-metrics that can measure the average time of PRs staying in review for a certain period of time. But you can use Github API to create your own action that will collect information important for your project.

Prepare your PR

Always start by adding a detailed description to your PR. If a visual representation would help, consider including diagrams. Proposing a review plan can also be a game-changer, guiding reviewers through a logical sequence, ensuring no change gets overlooked.
Before you request others to dive into your code, look through your draft PR yourself. This self-review allows you to catch and clean up any stray comments or oversights.
Comments within your PR should clarify your coding decisions, especially if there's potential for confusion. For instance, if you addressed an unrelated bug during the current PR, mention it. This preemptive clarification can save reviewers a lot of head-scratching. Annotations act as a roadmap through your changes. By directing reviewers to specific files or explaining the rationale behind certain modifications, you make their job simpler. The added perk? You might spot errors during this annotation phase, fixing them even before the review starts.
If you've addressed multiple issues in a PR, it might be the case that you need to divide it. PRs should be concise and focused. A rule of thumb: if a change touches more than five files, took over a day to draft, or would require an extensive review time, split it. For example, one PR could lay out the API for a new feature, and a subsequent PR could present the implementations.

How to review PRs of others

Treat code reviews with the same importance as any other task. Block off regular time slots in your calendar specifically for reviews. Swift feedback is crucial – the longer a developer waits, the hazier the context becomes, making it challenging to incorporate suggestions.
Code reviews aren't solely about catching bugs. They offer an opportunity to familiarize yourself with the team's evolving features and coding principles. Embrace this chance to learn and grow.
Your comments during a review should be lucid and constructive. Vague remarks can lead to confusion. Always aim to provide feedback that guides the developer towards the intended solution.
While platforms like GitHub are fantastic for code hosting and initial reviews, they might not be the best for extended discussions. Consider moving prolonged conversations to a platform like Slack for a more dynamic exchange.
For extensive pull requests, it can be beneficial to pull the branch into your local development environment. Tools like IntelliJ Idea can provide a more immersive diff view. Remember to use commands like git merge -no-commit -no-ff to see the changes as if you made them.

If you find certain parts of the code challenging to grasp, don't hesitate to ask the author in person for clarity. It's better to pause and understand than to provide feedback based on assumptions.

Reviewers Assignment Algorithm

There are different approaches to assigning reviewers automatically to PRs. For example randomly or using a matrix approach. GitHub provides two strategies https://docs.github.com/en/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team#about-auto-assignment
An alternative approach would be to have a custom strategy where each team member has a list of reviewers from his squad, but also two temporary reviewers from other squads.
Choose the approach which fits your team the best considering its size and feature delivering velocity.

The Speed of Code Reviews

While immediate reviews are ideal, they aren't always feasible. Nevertheless, a golden rule to adhere to is the 24-hour timeframe. Aim to respond to a code review request within one business day, even if it's just an initial assessment. This ensures that the code doesn't linger in review limbo, which could delay subsequent development stages.
By adhering to this rule, it's likely that a typical Change List (CL) undergoes multiple rounds of review within a single day, if necessary. Such quick turnarounds not only streamline the development process but also facilitate dynamic discussions between the reviewer and the developer, leading to a more refined codebase.

How to address the review comments

Instead of solely relying on Github comments, use Slack Github connection to facilitate communication on the PRs. It offers a dynamic platform for real-time interactions, making it easier to clarify doubts, seek explanations, and reach consensus on suggested changes.
If there's a particular comment or issue you plan to address later, leave a TODO tag accompanied by a task number. This ensures that you have a clear roadmap of pending actions and that these tasks aren't overlooked in future development stages.
If a particular code section sparks extended debate, it's crucial to document the decisions made. By adding comments explaining the choices and rationale, you prevent repetitive discussions in the future. It serves as a reference, ensuring that future developers or reviewers understand the context and reasoning behind specific code segments.

Links

Google guide: Code Review Developer Guide

Cisco research: https://static1.smartbear.co/support/media/resources/cc/book/code-review-cisco-case-study.pdf

Microsoft: 30 Proven Code Review Best Practices from Microsoft - Dr. McKayla

More readings on CR: https://blog.palantir.com/code-review-best-practices-19e02780015f

Best Practices for Android UI Testing

Roman Chugunov — Fri, 26 May 2023 18:45:09 +0000

In the previous article, we have discussed unit testing frameworks for Android that have recently become popular or were always a development standard. They are always placed at the foundation of the Test Pyramid. In this article, we will jump to one level higher, namely UI testing frameworks.

As with the previous article, I won’t touch upon the basics of writing tests using UI Automator and Espresso since it’s implied that you are already familiar with them. But I will offer you some advice on how to make your life easier when writing UI tests, as well as how to solve the most common problems. It’s not always possible to solve them with standard tools, so various plugins, extensions and frameworks often come to the rescue. I will cover those I have worked with myself and those I can recommend to you if you haven’t yet worked with them.

Espresso

So, UI tests. Espresso, a Google framework, is the gold standard here. There is a lot of documentation for Espresso, but in a nutshell almost every test is based on the following algorithm.

For elements found with ViewMatcher
Do some ViewAction
Check the result displayed on the screen using ViewAssertion

@RunWith(AndroidJUnit4::class)
class MainActivityTest {

    @Test
    fun test_clickRefreshButton_freshItemsAreLoaded() {
        onView(withId(R.id.nameEditText)).perform(typeText("Alex"));

        onView(withId(R.id.greetButton)).perform(click());

        onView(withId(R.id.greetingTextView)).check(matches(withText("Hi, Alex!")));
    }
}

Often, when tapping on some button, another screen may open. For this, we have another tool, IntentMatcher, that can check whether certain Intent was launched.

These four components, ViewAction, ViewMatcher, ViewAssertion, IntentMatcher, are the foundation of all UI tests. The example above is very simple, but on a complicated screen where a lot happens, the body of our test can grow significantly, and it will be a lot harder to read it. In order to improve the structure and readability of the tests, various design patterns are applied.

Design Patterns for Test Readability

Page Object Pattern: This pattern implies that each screen of an app is presented as a separate class that contains all interface elements and methods to interact with them. Therefore, a test scenario does not depend on the details of UI implementation and can be easily adapted to changes in design. This pattern is used in frameworks Kakao and Kaspresso (I will discuss it later in this article).
Screenplay Pattern: this pattern is an improved version of Page Object Pattern that adds another two components: actors and abilities. Actors are roles of users that perform actions in the app. Abilities determine how actors can interact with the app (for example, through Espresso or UiAutomator). This pattern allows you to write tests with a high level of abstraction and better display the app’s business logic.
Robot Pattern: this pattern is similar to Screenplay Pattern, but, intead of actors and abilities, robots that encapsulate the logic of interaction with screens are used. Robots can be re-used in different tests and combined with each other. This pattern simplifies the structure of tests and saves you from code duplication.

Espresso code written with the Robot pattern looks like this:

@RunWith(AndroidJUnit4::class)
class MainActivityTest {

    @Test
    fun test_clickRefreshButton_freshItemsAreLoaded() {
        login {
            setEmail("mail@example.com")
            setPassword("pass")
            clickLogin()
        }
        home {
            checkFirstRow("First item")
            clickRefreshItems()
            checkFirstRow("First ")
        }
    }
}

And the robot that encapsulates Espresso logic will look like this:

class HomeRobot {
    fun checkFirstRow(text: String) {
        onView(withId(R.id.item1)).check(matches(withText(text)))
    }

    fun clickRefreshItems() {
        onView(withId(R.id.button)).perform(click())
    }
}

fun home(body: HomeRobot.() -> Unit) {
    HomeRobot().apply { this.body() }
}

Therefore, if the test fails, we will know at what step something went wrong and what to do with this.

Ideally, our Espresso tests must be as simple and readable as unit tests. It’s not always possible if you cover with a test an entire flow consisting of several screens, at once. In this case, it is impossible to test one specific screen with high quality.

Flow Testing vs Screen Testing

When your Espresso test covers an entire flow, your test will look like this:

Open Screen A
Do Action 1
Make sure that the action was successful
Do Action 2
Make sure that Screen B was open
Do Action 3
Make sure that the action was successful

Here, we go through a so-called happy path and do not check any corner cases. In reality, this test is called end-to-end (e2e) test, and it must be as much as possible separated from the screen implementation (ideally, it must be written not using Espresso, but with other frameworks providing a higher level of abstration (UI Automator, Appium, or something else)). Due to their complexity, such tests can often fail, and it’s quite difficult to fix them. Also, they are quite expensive to run on CI, they can be run for minutes and even hours, so it’s not something you would like to run on every pull request. This is why, there can’t be a lot of such tests in a project.
Instead, we can have more atomic UI tests, which test only a specific screen. Such test would contain a simple set of actions:

Open a screen in onBefore
Do Action 1
Make sure that the action was successful

There can be a lot of such tests, they can cover both the happy path and various corner cases. Also, such tests are usually more stable. Thanks to their simplicity, the chance that something goes wrong and the test fails is far less. Though sometimes you can have a situation where your test is correct and the business logic it covers is also correct. You expect that the test will be green in 100% of the cases, but it turns out to be red in 1 case out of 100. Such tests are called flaky.

Flakiness

Probably, the main source of issues with flaky tests is network and other background operations. The thing is that when we perform a certain operation in a test (for example, click a button) and expect a certain result, this result may be delayed. By default, Espresso framework can wait for the completion of various operations, but it is about the operations with UI interaction only (for example, when another Activity opens with animation). Espresso doesn’t know anything about background operations related to our business logic. This leads to a possible failure of the test onView(withId(R.id.item1)).check(matches(withText(text))) because the expected text has not been loaded or displayed yet. However, the test will not always fail, but only when the Internet connection is slow on the emulator where the test was running. This is perhaps one of the most common issues with flaky tests. There are various methods to solve it:

Add Thread.sleep(…) to our test. This is a brute-force method and will help in the majority of cases, but, firstly, we are not immune from the delay being longer than sleep at any moment, and then the test will still fail. Moreover, sleep adds unnecessary delay to each run of the test, and even if the server works fast enough, our test will still run longer than we need.

Add Timeout and Retry to ViewMatcher. Something like this:

fun onViewWithTimeout(
    retries: Int = 10,
    retryDelayMs: Long = 500,
    retryAssertion: ViewAssertion = matches(withEffectiveVisibility(Visibility.VISIBLE)),
    matcher: Matcher<View>,
): ViewInteraction {
    repeat(retries) { i ->
        try {
            val viewInteraction = onView(matcher)
            viewInteraction.check(retryAssertion)
            return viewInteraction
        } catch (e: NoMatchingViewException) {
            if (i >= retries) {
                throw e
            } else {
                Thread.sleep(retryDelayMs)
            }
        }
    }
    throw AssertionError("View matcher is broken for $matcher")
}

This approach is used in the Kaspresso framework, which I will speak about below. This is far better than adding Thread.sleep(), but it still doesn’t guarantee that the timeout you set will be longer than the server delay. Moreover, such code hides slow pieces of your code, which is why, instead of introducing timeout and retry, it’s better to study why the server responds so long in this place and whether you should approach the issue from another side.

IdlingResource

As mentioned above, Espresso knows about Idle condition at the UI level, that is every next ViewAction from your test will be launched only when the previous one has finished and the system came to Idle state. But if you have some coroutine or Rx Observable that runs in the background and returns the result asynchronously, we need to somehow inform Espresso that we want to wait for the operation completion and perform the next ViewAction/ViewAssertion only after that. You can read about this in detail in the official documentation. Here I'll just give you a few hints that can be helpful in practice.

Your production code shouldn’t know anything about IdlingResource. You may have some interface in your app

interface OperationStatus {

    fun finished()

    fun reset()
}

And turn to this interface in the app to inform the test that the operation is complete:

coroutineScope.launch(coroutineDispatcher) {
    viewModel.usersFlow.collect {
        // show UI

        operationStatus.finished()
    }
}

And in androidTest, you will have the implementation of this interface that will know about IdlingResource. Correspondingly, you will be able to register it in IdlingRegistry.

class OperationStatusIdlingResource : OperationStatus {

    val idlingResource = CountingIdlingResource("op-status")

    override fun finished() {
        idlingResource.decrement()
    }

    override fun reset() {
        idlingResource.increment()
    }
}

@Test
fun test_clickRefreshButton_freshItemsAreLoaded() {

    val idlingResourceImpl = OperationStatusIdlingResource()
    IdlingRegistry.getInstance().register(idlingResourceImpl.idlingResource)

    // Test
}

How do you pass your OperationStatusIdlingResource to the app, given that it exists in tests only? Here, the second principle will help us out.

Use DI. It doesn’t matter if you use Hilt, Dagger or Koin, you will always have a dependency tree and a list of modules where we declare these dependencies (in our case, OperationStatus). For production code, you need to create a default dummy implementation that won’t do anything, and for a test, you need to override the module where the source dependency was, so that the DI tree worked with it. I will explain how to override DI dependencies below.

Do not use IdlingResource for special cases. In the example above, we have used it to signal that our data has been loaded at the screen opening. This is a special case of asynchronous data upload. Even within one screen, you can have multiple asynchronous operations, and creating a separate IdlingResource for each of them is excessive. It’s far better if you identify places where concurrency is introduced. For example, if your app is based on coroutines, asynchronicity will be introduced when Dispatchers.Default and Dispatchers.IO are used. It means that, in the tests, you need to replace these dispatchers with some test version, adding IdlingResource to it:

class SimpleViewModel(
    private val usersRepository: UsersRepository,
    private val coroutineScope: LifecycleCoroutineScope,
    private val coroutineDispatcher: CoroutineDispatcher = Dispatchers.Default,
) : ViewModel() {

    fun loadUsers(filter: FilterType) {
        coroutineScope.launch(coroutineDispatcher) {
            val allUsers = usersRepository.getUsers()
            // ...
        }
    }

And we can pass the following Dispatcher in the tests via DI:

class IdlingDispatcher(
    private val wrappedCoroutineDispatcher: CoroutineDispatcher,
) : CoroutineDispatcher() {

    val counter: CountingIdlingResource = CountingIdlingResource(
        "IdlingDispatcher for $wrappedCoroutineDispatcher"
    )

    override fun dispatch(context: CoroutineContext, block: Runnable) {
        counter.increment()
        val blockWithDecrement = Runnable {
            try {
                block.run()
            } finally {
                counter.decrement()
            }
        }
        wrappedCoroutineDispatcher.dispatch(context, blockWithDecrement)
    }
}

Using Fake objects in DI

Another useful practice that should be used in tests. By the way, if you don’t use DI in your project, you should start doing it.

In the examples above, I have described how to use fake implementations of IdlingResource in our production code, but haven’t discussed how to introduce them in tests. Let’s cover it in more detail using Dagger as an example.

If you don’t use dagger-android and prefer create a component manually, your Application will look more or less like this:

open class MyApplication : Application() {

    private lateinit var appComponent: ApplicationComponent

    override fun onCreate() {
        super.onCreate()

        appComponent = DaggerApplicationComponent
            .builder()
            .usersModule(UsersModule())
            .dataModule(DataModule())
            .build()
    }
}

In DataModule, we declare our dispatchers, and in UsersModule, we define the logic related to UsersRepository.

@Module
open class DataModule {

    @Provides
    @MyIODisptcher
    open fun provideIODispatcher(): CoroutineDispatcher = Dispatchers.IO

Please note that MyApplication, DataModule and provideIODispatcher are declared open so that it was possible to inherit from them in the tests.

Now, carry the creation of module DataModule over to a separate method:

open class MyApplication : Application() {

    private lateinit var appComponent: ApplicationComponent

    override fun onCreate() {
        super.onCreate()

        appComponent = DaggerApplicationComponent
            .builder()
            .usersModule(UsersModule())                 
            .dataModule(createDataModule())
            .build()
    }

    open fun createDataModule() = DataModule()

Then, in the androidTest folder, create a test class Application and redefine DataModule in it.

class MyTestApplication: MyApplication() {

    override fun createDataModule() = TestDataModule()
}

class TestDataModule {

    override fun provideIODispatcher(): CoroutineDispatcher = IdlingDispatcher()
}

In provideIODispatcher, we create an instance of our IdlingDispatcher that we’ve discussed above, and now, it will be used by default in all UI tests.

But this is not enough. We need to register our test app so that it would run together with the tests. For this, we will need to create a custom TestRunner where we will pass the name of the test app.

class MyApplicationTestRunner: AndroidJUnitRunner() {

    override fun newApplication(cl: ClassLoader?, className: String?, context: Context?): Application {
        return super.newApplication(cl, MyTestApplication::class.java.name, context)
    }
}

Now, we register this TestRunner in build.gradle:

android {
    namespace 'com.rchugunov.tests'
    compileSdk 33

    defaultConfig {
        applicationId "com.rchugunov.tests"
        minSdk 26
        targetSdk 33
        versionCode 1
        versionName "1.0"

        testInstrumentationRunner "com.rchugunov.tests.MyApplicationTestRunner"
     }

That’s all we need. In a way similar to IdlingDispatcher, we can also override other dependencies, replacing them with fake copies. For example, for UserRepository, such an implementation could look like this:

class FakeUserRepository: UsersRepository {

    var usersToOverride = listOf(
        User(id = "1", userName = "jamie123", age = 10),
        User(id = "2", userName = "christy_a1", age = 34)
    )

    override suspend fun getUsers(): List<User> {
        return usersToOverride
    }
}

Now, when you need to place a custom list of users, you can inject FakeUserRepository directly into your test and set the list usersToOverride that must return to ViewModel directly. This can be useful if you want to test only the presentation-layer, without the data-layer. An additional advantage would be that the tests will run faster since there will be no delays from server requests. Below, I will tell how else you can mock a client-server logic using Wiremock and OkReplay.

Similar to Dagger, you can also provide test implementations in Hilt and Koin.

How else can you make your life easier when writing and using UI tests? Start using Robolectric.

Robolectric

Robolectric is a rather old framework, it dates back to the times when arm-v7 emulators were run on x86 machines. It was very slow, and developers came up with the idea to extract Android AOSP and compile it in a jar file, and then run Espresso tests against it like on a real machine. Since the tests are actually run on a local computer (same as JUnit tests), it works far faster than the same tests on an emulator or on a device.

Robolectric is very simple to use; you need to add only a couple of lines to your existing Espresso tests. Here is an example of a test from the official page:

@RunWith(RobolectricTestRunner::class)
class MyActivityTest {

    @Test
    fun clickingButton_shouldChangeMessage() {

        Robolectric.buildActivity(MyActvitiy::class.java).use { controller ->
            controller.setup() // Moves Activity to RESUMED state
            val activity: MyActvitiy = controller.get()
            activity.findViewById(R.id.button).performClick()
            assertEquals((activity.findViewById(R.id.text) as TextView).text, "Robolectric Rocks!")
        }
    }
}

There are a lot of advantages to using Robolectric but the main one is the speed of the tests. However, there are certain limitations: for example, it can’t work with a device’s sensors, system buttons and Location services. Also, don’t forget that you are working only with a fake implementation of Android. In reality, your code may work in the Robolectric environment but will fail on the emulator for some reason. According to Jake Wharton, you'd better use Robolectric only if you are sure that you know how your tested code operates under the hood. I wouldn’t recommend running tests that cover the entire flow or user interaction with UI, with Robolectric. Here are a couple of examples of how you should use Robolectric:

You can test individual components of your app that use the data layer. For example, you can test the work with Room DAO.
1. Insert an object into a database
2. Fetch an object with the same id from a database
3. Check whether the same object has returned.
A test written with Robolectric will be ideal for this.
Opening deep links. Here, you can launch a Broadcast event and check whether a certain intent with a certain set of parameters has opened.
Working with a file system. This is the app’s data layer, so you can test it in isolation from the rest of the flow. In this case, you might need Context, and Robolectric is the tool that can provide it.

Therefore, Robolectric and Espresso together help you test both individual components of your app and an entire screen and flow. However, there are scenarios that can't be covered by them. For example, when we need to minimize the app, go to system settings, or give some Runtime Permission to the app. In this case, UI Automator is your saviour.

UI Automator

Espresso tests have one important feature — they are supposed to know about the production code that they are testing. You can receive a reference to some class object or inject a fake component of the app in the test. You have access to the app’s resources (R.id… R.string…, etc.). Thanks to this, you can write quite flexible tests that adapt to the app’s logic. Additionally, you can change the app’s logic so that it would work a bit differently when run under test.

On the contrary, UI Automator tests see your app as a user would. They see text fields, buttons, they can interact with UI elements, but they don’t know about their internal logic and condition. You can’t change the app’s logic or get access to some resources. Nevertheless, with UI Automator, you can do the following:

Interact with system apps and settings, such as homescreen, notifications and device settings. For example, here is how you can get access to the list of system notifications:

@Test
@Throws(UiObjectNotFoundException::class)
fun testNotifications() {
    device.openNotification()
    device.wait(Until.hasObject(By.pkg("com.android.systemui")), 10000)

    val notificationStackScroller: UiSelector = UiSelector()
        .packageName("com.android.systemui")
        .resourceId("com.android.systemui:id/notification_stack_scroller")
    val notificationStackScrollerUiObject: UiObject = device.findObject(notificationStackScroller)
    assertTrue(notificationStackScrollerUiObject.exists())

    val notiSelectorUiObject: UiObject = notificationStackScrollerUiObject.getChild(UiSelector().index(0))
    assertTrue(notiSelectorUiObject.exists())
    notiSelectorUiObject.click()
}

Android UI Automator can test complex scenarios that include switching between apps, for example, exchange of content or using Intents. Espresso can test scenarios only within one app and cannot process switching between apps or intents.

You can check or change system settings directly when running the test. This article covers how you can connect to Wi-Fi in a test.

// BySelector matching the just added Wi-Fi
val ssidSelector = By.text(ssid).res("android:id/title")
// BySelector matching the connected status
val status = By.text("Connected").res("android:id/summary")
// BySelector matching on entry of Wi-Fi list with the desired SSID and status
val networkEntrySelector = By.clazz(RelativeLayout::class.qualifiedName)
    .hasChild(ssidSelector)
    .hasChild(status)

// Perform the validation using hasObject
// Wait up to 5 seconds to find the element we're looking for
val isConnected = device.wait(Until.hasObject(networkEntrySelector), 5000)
Assert.assertTrue("Verify if device is connected to added Wi-Fi", isConnected)

As you can see, UI Automator, Espresso and Robolectric give an opportunity to test an app’s components in an isolated way and to check very complicated flows that include interaction with other apps and Android components. By the way, you can also combine tests and have Espresso tests together with UI Automator tests.

Compose UI Testing

And what about Compose? For testing Compose, there is a special set of APIs that sees Composables as individual Nodes. It also includes selectors and actions with which you can find UI elements and perform certain actions with them.

composeTestRule.onNode(hasTestTag("Players"))
    .onChildren()
    .filter(hasClickAction())
    .assertCountEquals(4)
    .onFirst()
    .assert(hasText("John"))

It’s good news that all these APIs are all about UI, similar to Espresso's ViewMatchers/ViewActions/ViewAssertions. It means that your tests will differ only slightly in syntax but you will still be solving the code cleanliness problems using patterns Robot or Page Object. To synchronize your background tasks and the test, you will be still using IdlingResource. In addition, you can substitute various objects in the DI tree, as we’ve done with the Espresso examples.

Moreover, you can still use Espresso API to test the integration of your app with an Android framework, for example, for navigation, animation and dialog windows.

@Test
fun androidViewInteropTest() {
    // Check the initial state of a TextView that depends on a Compose state:
    Espresso.onView(withText("Hello Views")).check(matches(isDisplayed()))
    // Click on the Compose button that changes the state
    composeTestRule.onNodeWithText("Click here").performClick()
    // Check the new value
    Espresso.onView(withText("Hello Compose")).check(matches(isDisplayed()))
}

Also, you can find articles that describe running of ComposeUI tests on Robolectric. Personally, I haven’t done it because I prefer not to test UI logic outside the emulator.

WireMock / MockWebServer

What else can help us write tests? Frameworks that can mock our network requests. We have discussed the option when, by creating fake objects and passing them to the DI tree, we can emulate some of the business logic and test only high-level logic (the Presentation layer). However, in some cases, it is still useful to have tests that cover all layers of the app at once. And then you can stumble upon problems, such as an unstable server or complicated replication of the required conditions. All this makes your tests flaky — we have discussed this above. Fortunately, there are frameworks that allow you to mock the client-server part.

Wiremock and MockWebServer provide similar functions to substitute the client/server interaction. Let’s use MockWebServer as an example.

Before running each test, we must launch the server and stop it after the test completion. It’s convenient to do this by creating a custom TestRule.

class MockWebServerRule : TestRule {

    lateinit val server: MockWebServer

    override fun apply(base: Statement, description: Description): Statement {
        return object : Statement() {
            @Throws(Throwable::class)
            override fun evaluate() {
                val server = MockWebServer()
                server.start(8080)
                try {
                    base.evaluate()
                } finally {
                    server.shutdown()
                }
            }
        }
    }
}

If you expect a certain order of performance of your requests, then you can make a queue of them within your test.

@RunWith(AndroidJUnit4::class)
class MyEspressoTest {

    @get:Rule
    val mockWebServerRule = MockWebServerRule()

    @Test
    fun test_some_action() {
        mockWebServerRule.apply {
            server.enqueue(MockResponse().setBody("..."))
            server.enqueue(MockResponse().setBody("Hello world!"))
            server.enqueue(MockResponse().setResponseCode(401))
        }

        // your test case
    }
}

Remember to provide test BaseUrl for Retrofit 127.0.0.1. You can do this the same way as we’ve covered above when we saved a fake UserRepository in TestApplicationComponent.

After this, you can run your test and, in response to all requests of your app, responses that you’ve added to the queue will return. Please note that the number and the order of requests must strictly match the number of responses set in the test. Otherwise, the test will most certainly fail. There is also an option to write a more granulated logic for processing app’s requests using request dispatcher Dispatcher:

@RunWith(AndroidJUnit4::class)
class MyEspressoTest {

    @get:Rule
    val mockWebServerRule = MockWebServerRule()

    @Test
    fun test_mock_with_dispatcher() {

        val requests = listOf(MockRule.USERS_REQUEST_FAILED_RESPONSE)

        mockWebServerRule.server.dispatcher = object : Dispatcher() {
            override fun dispatch(request: RecordedRequest): MockResponse {
                return requests.first { it.content.url == request.requestUrl }.content.response
            }
        }

                // YOUR TEST CODE

}

data class MockRuleContent(
    val url: String,
    val response: MockResponse,
)

enum class MockRule(val content: MockRuleContent) {
    USERS_REQUEST_POSITIVE_RESPONSE(MockRuleContent("/users/", MockResponse().setBody("[{\"name\": \"John\"}]"))),
    USERS_REQUEST_FAILED_RESPONSE(MockRuleContent("/users/", MockResponse().setResponseCode(404)))
}

WireMock has similar functionality, but it’s harder to use than MockWebServer and the support of the Android community is not so strong. In addition, WireMock has an important feature: you can run the server in the record mode, so that you can run your tests in the online client/server interaction mode. WireMock can write all responses from the server and save them in a file. After this, you will be able to run the same test but with already recorded mocks. MockWebServer can’t do this, but OkReplay is perfect for this task.

OkReplay

With OkReplay, you can prepare test stubs on the basis of real server requests (similar to WireMock). To use it, you need to add the interceptor OkReplayInterceptor in the Retrofit/OkHttp test configuration. Then, with the Gradle plugin, you can run your tests in the mode of recording requests and responses from the service into .yaml files (they are called Tapes). Also, OkReplay provides a Gradle plugin that includes tasks to extract recorded tapes from a device or an emulator, as well as for their cleaning.

./gradlew clearDebugOkReplayTapes - Cleaning tapes
./gradlew pullDebugOkReplayTapes - Pulling tapes from the device or emulator

In order to run a test in the tape record or replay mode, you need to pass the corresponding parameter TapeMode into the OkReplay configuration:

private val activityTestRule = ActivityTestRule(MainActivity::class.java)
private val configuration = OkReplayConfig.Builder()
    .tapeRoot(AndroidTapeRoot(InstrumentationRegistry.getInstrumentation().targetContext, javaClass))
    .defaultMode(TapeMode.READ_WRITE) // или TapeMode.READ_ONLY
    .sslEnabled(true)
    .interceptor(okReplayInterceptor)
    .build()

@JvmField
@Rule
val testRule = OkReplayRuleChain(configuration, activityTestRule).get()

@Test
@OkReplay
fun myTest() {
    ...
}

OkReplay framework simplifies the network request testing process in Android apps, ensuring safer and more predictable results. However, there is an important factor: you need to have tests that can actually reproduce scenarios of the app behaviour (for example, specific errors from the server). It is often quite difficult to reproduce such conditions, and recording tapes is, therefore, problematic.

Developers have been trying to solve all the above issues for quite some time. You can find lots of open-source libraries on Github that, in fact, wrap Espresso API but also help to solve some of its issues and add various delightful features. I’m going to tell you about two of them, Barista and Kaspresso.

Barista

Barista is an additional layer of abstraction for Espresso, so it has several additional features as compared to Espresso. Firstly, it adds a number of methods for more comfortable work with UI elements.

For example, instead of original Espresso code:

@Test
fun myTest() {
    onView(withId(R.id.first_name))
        .perform(typeText(FIRST_NAME), ViewActions.closeSoftKeyboard())
    onView(withId(R.id.second_name))
        .perform(typeText(SECOND_NAME), ViewActions.closeSoftKeyboard())
    onView(withId(R.id.save)).check(matches(isEnabled()))
    onView(withId(R.id.save)).perform(click())
        // write your test as usual...
}

We can write this:

@Test
fun myTest() {

    writeTo(R.id.first_name, FIRST_NAME)
    closeKeyboard()

    writeTo(R.id.second_name, SECOND_NAME)
    closeKeyboard()

    assertEnabled(R.id.save);

    clickOn(R.id.save)

    assertDisplayed(FIRST_NAME)
}

The test has admittedly become more readable. A disadvantage is that you need to keep in mind even more various ViewMatcher/ViewAction and other elements than in regular Espresso. However, you can still use the Robot pattern to make your tests more expressive. You can learn more about available methods here. Barista also provides a number of convenient test rules, for example, for database and SharedPreferences cleanup:

// Clear all app's SharedPreferences
@Rule public ClearPreferencesRule clearPreferencesRule = new ClearPreferencesRule();

// Delete all tables from all the app's SQLite Databases
@Rule public ClearDatabaseRule clearDatabaseRule = new ClearDatabaseRule();

// Delete all files in getFilesDir() and getCacheDir()
@Rule public ClearFilesRule clearFilesRule = new ClearFilesRule();

But whether you should use them or write everything yourself is a good question. Our apps often become so complicated that using standard tools is impossible, so every developer prefers to write their own custom logic.

Kaspresso

Another Espresso wrapper, created by Kaspersky Antivirus developers. But this framework provides far more features than Barista. Firstly, it makes you write tests using Page Object pattern by default. It is an undeniable advantage since the test will look cleaner and more abstracted from the used Views and their IDs.

object SimpleScreen : KScreen<SimpleScreen>() {

    override val layoutId: Int? = R.layout.activity_simple
    override val viewClass: Class<*>? = SimpleActivity::class.java

    val button1 = KButton { withId(R.id.button_1) }

    val button2 = KButton { withId(R.id.button_2) }

    val edit = KEditText { withId(R.id.edit) }
}

Another important Kaspresso’s feature is that all ViewActions include some timeout to deal with flaky tests, which is useful in cases when we wait for a response from the backend. This may be convenient but is not too reliable as setting timeout is sometimes not sufficient. I recommend relying more on IdlingResource and predefined server responses using OkReplaly or server response mocks.

Additionally, Kaspresso provides numerous other useful features, like running adb prompts right from the test and interaction with the Android system. Taking into account that all of this is available in a ready-made solution, Kaspresso is an excellent substitute for the traditional Espresso.

Conclusion

Like many other developers, I’ve encountered many difficulties while writing Espresso tests. The tests are often complicated, slow and flaky. However, we now have a lot of libraries, frameworks and approaches that can significantly simplify and speed up the UI tests writing process. If I were to start working on a new app just now, I would write UI tests with Kaspresso at once. IdlingResource is a must for synchronization of background tasks and the test itself. If possible, use fake implementations of your repositories or record your requests and responses with OkReplay. Take care of the cleanliness and tidiness of your tests with Page Object and Robot patterns. If you follow these recommendations, you will be able to significantly improve the quality of your tests and reduce the number of bugs in the Android app code.

Best practices for Unit Testing Android Apps with Mockk, Kotest and others

Roman Chugunov — Wed, 10 May 2023 07:57:54 +0000

Perhaps you write unit tests, or maybe you don’t. With this article, I’m not aiming to persuade you to do it, rather I’d like to demonstrate how far the world of unit tests has advanced and how much easier it is to write unit tests now, as opposed to how Android developers did it 10 years ago. Please also note that I’ll be talking about testing done by developers and not by QA engineers, so we won’t go into high-level frameworks like Appium.

From the point of view of the Test Pyramid, in this article, I will only describe the lower layer, namely unit tests. However, I’m planning on writing one or two other articles dedicated to UI tests with frameworks like Espresso, as well as code coverage and visual reporting for test results. Right now, I’m not planning on touching on the subject of CI/CD setup as it’s quite a major topic, and mobile developers are often not responsible for it (or not all developers).

So, unit tests are tests that cover the logic of individual parts of an app, be it ViewModel, Repository, Usecase, DataSource, or other components. Normally unit tests do not test Activity and other Android components, because, in such a case, we would have to run the tests on an Android device or an emulator, while Repository testing can be done on a local computer where your development environment is installed. Of course, there is the Robolectric framework, but it rather deals with testing UI components.

Ten years ago, classical unit tests for Android were written using the JUnit framework, and even now it’s the most popular framework for such tests. Let’s look at some of its features.

JUnit

Currently, we have two versions of this framework, JUnit 4 and JUnit 5. The first letter in the name means that the framework was originally developed to test Java code, but it works perfectly well for Kotlin code, too. Below, you can see several examples of tests written using JUnit 4.

Assume we have a simple ViewModel that includes loadUsers method:



class SimpleViewModel : ViewModel() {

    fun loadUsers(): List<User> {
        return listOf(User(id = "1", userName = "jamie123"))
    }
}

This method is very dumb, so all we can do is to check if it returns what we expect it to return. To do this, we can write the following test.



class SimpleViewModelTest {

    private val viewModel = SimpleViewModel()

    @Test
    fun testReturnUsers() {
        val result = viewModel.loadUsers()
        assertEquals(listOf(User(id = "1", userName = "jamie123")), result)
    }
}

As you can see, we just check if the result of the method execution equals a certain expected value. Assert.asserEquals method helps us with this. The Assert class includes lots of other useful methods for such checks. I recommend going through all the available methods.

Let’s add some logic to our loadUsers method. We add a parameter that will return only adult users (older than 18).



fun loadUsers(onlyAdults: Boolean): List<User> {
    val allUsers = listOf(
        User(id = "1", userName = "jamie123", age = 10),
        User(id = "2", userName = "christy_a1", age = 34)
    )
    return if (onlyAdults) {
        allUsers.filter { it.age >= 18 }
    } else {
        allUsers
    }
}

For this method, we can write two tests: the first one will check the upper branch of if (onlyAdults), and the second—the lower branch.



@Test
fun testReturnOnlyAdultsUsers() {
    val result = viewModel.loadUsers(onlyAdults = true)
    assertEquals(
        listOf(
            User(id = "2", userName = "christy_a1", age = 34)
        ), result
    )
}

@Test
fun testReturnAllUsers() {
    val result = viewModel.loadUsers(onlyAdults = false)
    assertEquals(
        listOf(
            User(id = "1", userName = "jamie123", age = 10),
            User(id = "2", userName = "christy_a1", age = 34)
        ), result
    )
}

So, everything is quite simple. Unit tests allow us to test various scenarios of the logic within methods. We enter some parameters and check the result with the expected value.

JUnit 4 includes basic testing features. Writing tests with it is simple and convenient.

JUnit 5

JUnit 5 has many pleasant additions. Also, the list of key annotations somewhat changed: for example, @Before became @BeforeEach, and @After—@AfterEach. In addition, the package hierarchy totally changed. All main classes and annotations are now available through path org.junit.jupiter.api.* . Let’s consider several key features new to JUnit 5.

@DisplayName Annotation

This annotation makes names of your tests more expressive.



@DisplayName("Test return only adults users")
@Test
fun testReturnOnlyAdultsUsers() {
    val result = viewModel.loadUsers(onlyAdults = true)
    assertEquals(
        listOf(
            User(id = "2", userName = "christy_a1", age = 34)
        ), result
    )
}

Although Kotlin developers can use such test naming even without a special annotation, using backticks.



@Test
fun `Test return only adults users`() {
        ...
}

@DisplayName’s advantage is that it can also be applied to the class name.



@DisplayName("Tests for SimpleViewModel")
class SimpleViewModelTest {

Together with such naming of test methods, we can follow the GivenWhenThen approach. So our test will look as follows:



@DisplayName("WHEN pass onlyAdults = true THEN return expected items")
@Test
fun testReturnOnlyAdultsUsers() {
    val result = viewModel.loadUsers(onlyAdults = true)

Or like this:



@Test
fun `WHEN pass onlyAdults = true THEN return expected items`() {
        ...
}

One must admit that now the test name describes its structure more clearly.

@Disabled Annotation

In addition, if you follow TDD and write a lot of tests that don’t always run on the go, JUnit 5 has a convenient annotation @Disabled that allows you to turn off tests that don’t work for some reason or were written for code to be added yet.



@Disabled("Code not implemented yet")
@Test
fun `WHEN pass onlyAdults = true THEN return expected items`() {

Remember that turning off failed or unstable tests is a bad practice. You should repair such tests or the code that made them fail at once.

Parameterized tests `@ParameterizedTest`

Let’s now consider a case when our method loadUsers receives enum as input.



fun loadUsers(filter: FilterType): List<User> {
    val allUsers = listOf(
        User(id = "1", userName = "jamie123", age = 10),
        User(id = "2", userName = "christy_a1", age = 34)
    )
    return when (filter) {
        FilterType.ADULT_USERS -> allUsers.filter { it.age > 18 }
        FilterType.CHILD -> allUsers.filter { it.age < 18 }
        FilterType.ALL_USERS -> allUsers
    }
}

To check all three conditions, we can write three different tests. Alternatively, we can write a parameterized test that will receive as input a parameters array and expected values and then compare them:



@ParameterizedTest
@MethodSource("testArgs")
fun `WHEN pass onlyAdults = true THEN return expected items`(argAndResult: Pair<FilterType, List<User>>) {
    val result = viewModel.loadUsers(argAndResult.first)
    assertEquals(argAndResult.second, result)
}

companion object {
    @JvmStatic
    fun testArgs(): List<Pair<FilterType, List<User>>> = listOf(
        FilterType.CHILD_USERS to listOf(User(id = "1", userName = "jamie123", age = 10)),
        FilterType.ADULT_USERS to listOf(User(id = "2", userName = "christy_a1", age = 34)),
        FilterType.ALL_USERS to listOf(
            User(id = "1", userName = "jamie123", age = 10),
            User(id = "2", userName = "christy_a1", age = 34)
        )
    )
}

In this example, I use an additional annotation @MethodSource which will include the method providing our parameters. This method must be static (located in a companion object and having @JvmStatic annotation) and return a list or a sequence of parameters. And in the very test method we receive an element of this list. In our case, it’s Pair<FilterType, List<User>>. This way the test method becomes as simple as possible: we just call a tested method with the first test argument value and compare the result with the second one.

Besides MethodSource, there are numerous other sources of arguments for parameterized tests.

Probably, you’ve noticed that we have been testing clean methods, with the result depending neither on the condition of the class nor on other classes. The user list was hardcoded into the method. In real life things are always more complicated. So, let’s take a look at a situation when our view model receives the user list from a repository.



class SimpleViewModel(private val usersRepository: UsersRepository) : ViewModel() {

    fun loadUsers(filter: FilterType): List<User> {

                val allUsers = usersRepository.getUsers()
                return when (filter) {
            FilterType.ADULT_USERS -> allUsers.filter { it.age > 18 }
            FilterType.CHILD_USERS -> allUsers.filter { it.age < 18 }
            FilterType.ALL_USERS -> allUsers
        }
    }
}

The purpose is the same: we want to test the logic of the SimpleViewModel method. But we don’t know (and don’t want to know) what UsersRepository returns. For this, we can use a mock framework, for example, Mockito.

Mockito

Mockito and similar frameworks allow us to change the logic of classes and methods which we do not test directly but which are part of the code. In our example, we can simulate the execution of usersRepository.getUsers() method when the list of expected Users is returned to us, in order to check the execution of loadUsers method. I won’t go into much detail about Mockito’s syntax as it has many features and nuances. However, the two key features are: it can replace a method’s returning value; it can also check if the replaced method has been called with the expected parameters. In this case, our test will look like this:



private val mockUsersRepository: UsersRepository = mock()
private val viewModel = SimpleViewModel(mockUsersRepository)

@BeforeEach
fun setup() {

    mockUsersRepository.stub {
        on { getUsers() } doReturn listOf(
            User(id = "1", userName = "jamie123", age = 10),
            User(id = "2", userName = "christy_a1", age = 34)
        )
    }
}

@ParameterizedTest
@MethodSource("testArgs")
fun `WHEN pass onlyAdults = true THEN return expected items`(argAndResult: Pair<FilterType, List<User>>) {
    val result = viewModel.loadUsers(argAndResult.first)
    assertEquals(argAndResult.second, result)
    verify(mockUsersRepository).getUsers()
}

As you can see, I create mockUsersRepository object using mock( function. Then, in setup() method, I set up this repository in such a way so that it would return a list of hardcoded values. After this, on top of everything else, I check if, for mockUsersRepository object, getUsers method was called with verify function, in the test method. It’s important to note that Mockito is a very old framework and was originally written for Java. When Kotlin appeared, it turned out that out of the box this framework can work with some limitations, which is why an extension, mockito-kotlin, was released. The example above was written with it. Another Mockito’s limitation was that it was impossible to mock final classes and static methods, and all classes are final by default in Kotlin. Currently, this is solved through mockito-inline but, before, it was a serious limitation. In respect to Java development, there was and is an alternative for Android developers, PowerMock.

PowerMock

This framework was intended to eliminate Mockito’s limitations with regard to mocking final, static and private methods. It successfully solves this issue but, at the same time, is a bit harder to use. For example, we can mock a static method as follows:



mockStatic(MyClass::class.java)
when(MyClass.firstMethod(anyString())).thenReturn("Some string");

Much of this is now available in Mockito. Even more - naturally Kotlin doesn’t have static methods, and it’s a good practice not to create them. Ideal code is code that follows the SOLID and Clean Architecture principles, which means it can be easily mocked and tested. Therefore, we, Android developers, don’t need PowerMock’s special features but it’s important to remember that such frameworks exist. Another Mockito’s limitation concerns work with coroutines and flows. In such cases, once again, mockito-kotlin as well as third-party libraries like turbine will help you out. This being said, I’d like to tell you about another alternative to Mockito, which is Mockk.

Mockk

Mockk is a rather new framework; it was originally designed for Kotlin, although it supports Java as well. Before mockito-kotlin was released, using Mockk was much easier and beneficial for Kotlin developers, but right now both these frameworks have nearly the same set of features and similar syntax. For example, assume that our function loadUsers is no longer synchronous, but rather suspended:



interface UsersRepository {
    suspend fun getUsers(): List<User>

Regular Mockito can’t mock it. That’s why need the mockito-kotlin extension. With it, our mock will look like this:



@BeforeEach
fun setup() {
    mockUsersRepository.stub { onBlocking { getUsers() } doReturn listOf(User("user_id")) }
}

In Mockk, the mock of the same function will be this way:



@BeforeEach
fun setup() {
    coEvery { getUsers() } returns listOf(User("user_id"))
}

As you can see, it’s a matter of taste.

However, an important distinction between Mockk and Mockito is that all Mockk’s mocks do not have default values. In Mockito, a method that returns Unit will be expectedly called, and a method that returns a reference type will return null. This may cause unfavorable consequences: if we can handle this null value in our production code, it is obvious that the test will work incorrectly hiding the NPE. In Mockk, any method of the mock class throws an exception by default, although it is possible to create relaxed mocks in order to achieve a behavior similar to that of Mockito.



private val mockUsersRepository = mockk<UsersRepository>(relaxed = true)

In fact, it is an anti-pattern because it can lead to developers missing errors hidden by relaxed mocks. However, it may sometimes be useful not to create mocks for functions that return Unit. For this, Mockk has a special parameter:



private val mockUsersRepository = mockk<UsersRepository>(relaxUnitFun = true)

It is probably the main difference between Mockk and Mockito. But it is up to you to decide whether it’s an advantage and whether you should change your framework because of it.

Now that we’ve learned about the frameworks to create mocks for unit tests, I’d like to make the task a bit more complicated. In our example, SimpleViewModel class has only one dependencyusersRepository, and this repository, in turn, contains only one method. In real life, your tested class can have a dozen of dependencies, with a set of methods closely related to each other. That’s why viewModel.loadUsers method may be a lot more complicated. In the example below, we combine several Observables to derive the final result.



fun init() {
        observeUserAvailability()
                .subscribeNext { result ->
                        // check result
                }
}

private fun observeUserAvailability(draftPotUuid: String): Observable<UserAvailability> = Observable.combineLatest(
        usersRepository.observeCurrentUser(),
        profileRepository.observeCurrentProfile(),
        kycRepository.observeKycStatus(),
        addressRepository.loadCurrentUserAddress(),
        countryRepository.observeCountries(),
    )

To test a set of scenarios for init() method, you need to have a set of tests with duplicated methods for mocking observeCurrentUser, observeCurrentProfile , and others. We could add them into BeforeEachmethod but then, we would want to be careful and not to forget to update default mocks where they are not needed. Nested classes of JUnit 5 can help you solve this issue.

Nested classes in JUnit 5

Using nested (or inner for Kotlin) classes, we can group tests with some common conditions. For example, we can create two groups of tests depending on what usersRepository.observeCurrentUser() method returns. In the first case, it will return the correct user User("user_id"), while in the second case—a user with incorrect ID User(null):



@DisplayName("Tests for SimpleViewModel")
class SimpleViewModelTest {

    private val mockUsersRepository: UsersRepository = mock()
    private val viewModel = SimpleViewModel(mockUsersRepository)

    @DisplayName("GIVEN userRepository returns correct user")
    @Nested
    inner class MockGroup1 {

        @BeforeEach
        fun setup() {
            mockUsersRepository.stub { on { getCurrentUser() } doReturn User("user_id") }
        }

        @Test
        fun `GIVEN kycRepository returns kycPassed WHEN init viewModel THEN get expected result`() {
            ///
        }
    }

    @DisplayName("GIVEN userRepository returns incorrect user")
    @Nested
    inner class MockGroup2 {

        @BeforeEach
        fun setup() {
            mockUsersRepository.stub { on { getCurrentUser() } doReturn User(null) }
        }

        @Test
        fun `GIVEN kycRepository returns kycPassed WHEN init viewModel THEN get expected result`() {
            ///
        }
    }

Following this example, we can extend this approach to grouping tests and create as many nested levels as we need, as long as they remain readable and understandable to us and other members of our team. Try to adhere to the KISS principle.

JUnit 5 and the abovelisted frameworks have many other interesting features. I have described only those that I use myself and which I consider highly useful to us, Android developers.

TDD vs BDD

As a matter of fact, in the previous examples, we have shifted a bit away from the TDD standards in the meaning that we test not only the operability of our code, but rather check if the code runs according to certain specifications (Given/When/Then). These specifications are our tests, and the syntactic sugar in the form of the possibility to give clear names to the tests using DisplayName and the grouping of the tests by a set of similar attributes helps us clearly formulate these specifications. There is an entire family of frameworks in different languages that allow us to create such specifications: for Java it is Spock, for Ruby—RSpec, and for Kotlin—Spek and Kotest frameworks. Below, I will go into more detail about them.

Spek

Spek is a BDD framework where we describe the conditions in which the tested object must work and its reaction to these conditions, in detail. We by default make the test body from several units, to differentiate between the areas of responsibility (what we are testing, the conditions and the expected result). If we go back to our SimpleViewModel the tests will look like this:



class SimpleViewModelSpec : Spek({

    val mockUsersRepository: UsersRepository = mock()
    val viewModel by memoized { SimpleViewModel(mockUsersRepository) }

    describe("loadUsers") {

        beforeEachTest {
            // do mocking
        }

        it("should return only adult users if pass filterType: adult users") {
                val result = viewModel.loadUsers(FilterType.ADULT_USERS)
            assertEquals(listOf(User(id = "2", userName = "christy_a1", age = 34)), result)
            verify(mockUsersRepository).getUsers()
        }
    }
})

As you can see, our testing logic is written as a lambda expression, and each test is a kind of mapping from the line, the test name, and the very unit running the test.

The describe-it style is mainly used to write Spek tests. describe structure allows us to create a group of tests describing a specific method, and, in it, a specific scenario for the method is written. But it is also possible to use the GivenWhenThen style. Unfortunately, the framework doesn’t have embedded coroutine support, so we have to always use runBlockingTest { } for suspended functions. There is a ticket with this feature request on Github, but it seems it was never completed.

Spek doesn’t provide its own asserts, mocks or matchers, but it allows you to work with other libraries, such as Mockk and Mockito.

Kotest

Another framework that, in terms of its syntax and behavior, is similar to Spek. It has also recently gained popularity among Android developers thanks to its Kotlin-first principle and flexibility. Perhaps, flexibility first and foremost means that you can choose the style to write your tests. Currently, you can choose from 10 styles. Personally, I prefer FreeSpec. The above tests will look like this if written in Kotest:



class SimpleViewModelSpec : FreeSpec({

    val mockUsersRepository: UsersRepository = mock()
    val viewModel = SimpleViewModel(mockUsersRepository)

    beforeTest {
        // do mocking
    }

    "WHEN pass filterType: adult users" - {

        val result = viewModel.loadUsers(FilterType.ADULT_USERS)

        "THEN return only adult users" {
            assertEquals(listOf(User(id = "2", userName = "christy_a1", age = 34)), result)
            verify(mockUsersRepository).getUsers()
        }
    }
})

The test above works in the FreeSpec style according to the GivenWhenThen principle.

Kotest has embedded coroutine support, which is why, as opposed to Spek, you won’t have to use runBlockingTest { } for suspended functions.

Test isolation level, which differs from JUnit 4/5, is important here. The values of mocks and the test conditions are not cleared after each test. If you want a behavior similar to JUnit, use isolationMode = IsolationMode.InstancePerLeaf flag.



class SimpleViewModelKoTest : FreeSpec({

        isolationMode = IsolationMode.InstancePerLeaf

Also, Kotest provides an additional set of asserts and matchers that may be more convenient than those that we’ve used with Mockito. If your project already uses Mockito and JUnit, that’s alright, as tests written in Kotest can co-exist with JUnit.

Conclusion

Today, there are many unit testing frameworks and libraries for Android apps. I have described only the most popular ones, but there are more. If you work on enterprise Android projects you are most likely used to writing unit tests with some of mentioned in this article technologies. As a rule, large companies use time-tested tools, such as JUnit and Mockito. But, as new Kotlin features continue to be released, numerous new testing libraries and frameworks are appearing. I can definitely recommend you to try out Mockk or Kotest, if you haven’t used them before. They can make your life much easier and improve the quality of your tests.

In the next article, I will tell you about the approaches and best practices used when writing UI tests. Also, please share your own experience in using unit tests in your projects: what frameworks do you use?

Reusing Gradle modules in several applications

Roman Chugunov — Sun, 26 Feb 2023 18:46:05 +0000

Reusing Gradle modules in several applications

Hey guys! I’ve been working as an Android developer for quite some time now and I have to say: today’s apps have clearer architecture and are modular, as compared to the apps of ten years ago. Multi-modularity (or, at least, a couple of Gradle modules in a project) is de facto a modern standard. Any project, as a rule, has the main app module, several feature modules, as well as core/domain/data modules.

These modules are connected in a quite standard way:

When you have one app, it’s not a problem: all the modules co-exist and we don’t really care about the connections between modules, though, of course, we should avoid circular dependencies.

As a matter of fact, we can surely have several apps in one project. To do this, we just need to add another :app Gradle module, declare the android.application plugin in it, and — ta da! Android Studio shows another launch option.

For example, we are working on two apps: CatsApp, for cat-lovers, and another one, DogsApp, for dog persons. All the features are the same (we have a screen to display a list of cats and dogs and a screen for detailed information); only the main modules differ. Among other things, different network configurations and themes.xml files may be declared and DI trees initialise differently in these modules. You can find an example of such a project here.

A more common example is probably the case when a project has its own design system, and we need a demo app to view our UI components, aside from the main app.

Option 2

This is the case when we have two independently developed apps within the same company, and the business requirements dictate that different features were united or all the features of one app were reused in the other.
Here, multi-modularity will save the day because we already have an isolated piece of code that is partially ready for reuse. At the same time, these modules exist in different repos, are not associated with each other, and have different dependency lists of their own.
How do we unite modules from different projects? First of all, we can just set up visibility of a project for the other one, by simply uploading them into neighbouring directories and updating settings.gradle of the main project by including the other app’s modules into it.

project(':feature-list').projectDir = new File('../app_to_be_reused/feature-list')

include ':feature-details'
project(':feature-details').projectDir = new File('../app_to_be_reused/feature-details')

include ':domain'
project(':domain').projectDir = new File('../app_to_be_reused/domain')

Unfortunately, if we only need :feature-list, we will also have to add dependencies of that module into our project, i.e. to pull :domain and :feature-details.

If we haven’t prepared the modules of the reused project beforehand, it will cause lots of issues even when we just try to import everything we need and synchronise the main project. For instance, if our reusable :feature-1 module has Activities they won’t be able to use themes defined in the main project :cats-app.
Also, both projects are different Git repositories, so we’ll have to take care about being on the correct branches, while synchronising modules. It is highly possible that the Gradle configuration has changed in the reused project, which is why we need to always check whether we work in the right version of the project. It, in turn, causes problems with CI builds that now have to fetch two projects instead of one and build and test two projects in the same pipeline.

Git submodules can somewhat help us. They allow us to include another repo into the existing one and tag the correct version of the project with dependencies. You can learn more about submodules here. In this case, the dependency diagram will be similar to the one from the previous example.

Anyways, you as the developer of another app will have to dive deep into another team’s code, with the learning curve quite possibly being rather steep. Please see an example of using two projects where one links the other’s modules here.

Option 3

This option is based on publication of a part of the reused app in a separate Android library so that the other app could link it and use it as any other third-party SDK. If the app with dependencies is rather modular, you can try to export the modules you need, and then add entry points for them from the other app. As a rule, we use the maven-publish Gradle plugin for publishing pure Java/Kotlin libraries, but Android Gradle Plugin has recently started supporting it, and we can now export Android modules, and not merely Java libraries.
Here’s an example. Our DogsApp consists of the modules app, feature-list, feature-details and domain. Feature-list is responsible for printing out information about and the image of a certain dog. domain includes general information reused in all the other modules.

At some point, our company, for example, acquires another start-up business that has developed CatsApp. The business requirements now dictate that we support the new app and update its features by adding the same screen for viewing the details of cats, like in DogsApp. Since the apps were developed separately, they have different dependency trees, and we cannot just use the first two approaches, i.e. merge the codebases or link the modules we need from DogsApp into CatsApp. But we can take advantage of library publication. In this case, we need to publish feature-details.
To do this, we’ll use the maven-publish plugin and add the following code into feature-details build.gradle:

android {
   ...
   publishing {
       singleVariant('release')
   }
}

afterEvaluate {
   publishing {
       publications {
           release(MavenPublication) {
               from components.release
           }
       }
   }
}

singleVariant points that we want to publish only one build option. To make it possible to use both the debugging and release versions of our library, we need to use allVariants() and components.default:

   ...
   publishing {
      multipleVariants {
         allVariants()
      }
   }
}

afterEvaluate {
   publishing {
       publications {
           allVariants(MavenPublication) {
               from components.default
           }
       }
   }
}

Now we can publish our module with the gradle :feature-details:publishToMavenLocal command. Let’s add a local maven repo to CatsApp so that we could use this dependency:

settings.gradle:

dependencyResolutionManagement {
    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
       google()
       mavenCentral()
       mavenLocal()
   }
}

Now, we can add the dependency to the exported library in cats_app/build.gradle:

dependencies {
   ...
   implementation 'com.example:feature-details:1.0.0'
}

However, when we try to build CatsApp, build errors will occur because the build system cannot find the :domain module, so we need to publish it too. In fact, we have to recursively publish all the dependencies that the :feature-details module uses. For this, delete the code that we’ve added before for the publication of :feature-details and add the following into the root build.gradle:

subprojects {
   apply plugin: "maven-publish"

   afterEvaluate {
       if (!plugins.hasPlugin("android")) {

           if (plugins.hasPlugin("android-library")) {
               android {
                   publishing {
                       multipleVariants {
                           allVariants()
                       }
                   }
               }
           }

           publishing {
               publications {
                   allVariants(MavenPublication) {
                       afterEvaluate {
                           if (plugins.hasPlugin("java")) {
                               from components.java
                           } else if (plugins.hasPlugin("android-library")) {
                               from components.default
                           }
                       }
                   }
               }
           }
       }
   }

Subprojects { means that we want to apply our code to all the submodules. But we don’t want to publish the main module :dogs-app, so we filter it out by the presence of Android plugin !plugins.hasPlugin("android"). Please also note that :domain is a Java library and doesn’t have build options, which is why we don’t need to add this information to it. We will add build options for Android libraries only:

 if (plugins.hasPlugin("android-library")) {
     android {

Also, since we have both Java and Android modules, we’ll have to use different publication methods. If a Java plugin has been applied to a module, it will be published as a Java library, and in case of the Android library plugin, we’ll publish a set of .aar archives with corresponding build options.

if (plugins.hasPlugin("java")) {
    from components.java
} else if (plugins.hasPlugin("android-library")) {
    from components.default
}

Now, when we publish our library with the same gradle :feature-details:publishToMavenLocal command, all the dependencies will be placed into our local maven repository, and the client app CatsApp will be built with no issues. You can find the full code here.

What about you? Have you ever had to merge different apps or reused another team’s Gradle dependencies? Please share the approach used in your company in the comments.

DEV Community: Roman Chugunov

Practical tips for code reviews in large teams

How to measure Code Review effectiveness

Prepare your PR

How to review PRs of others

Reviewers Assignment Algorithm

The Speed of Code Reviews

How to address the review comments

Links

Best Practices for Android UI Testing

Espresso

Design Patterns for Test Readability

Flow Testing vs Screen Testing

Flakiness

IdlingResource

Using Fake objects in DI

Robolectric

UI Automator

Compose UI Testing

WireMock / MockWebServer

OkReplay

Barista

Kaspresso

Conclusion

Best practices for Unit Testing Android Apps with Mockk, Kotest and others

JUnit

JUnit 5

@DisplayName Annotation

@Disabled Annotation

Parameterized tests @ParameterizedTest

Mockito

PowerMock

Mockk

Nested classes in JUnit 5

TDD vs BDD

Spek

Kotest

Conclusion

Reusing Gradle modules in several applications

Reusing Gradle modules in several applications

Option 2

Option 3

Parameterized tests `@ParameterizedTest`