DEV Community: Ritwik Jamuar

Jetpack Compose + MVI - Part 2: Testing

Ritwik Jamuar — Thu, 25 May 2023 12:30:00 +0000

Previously, I had discussed how to handle any side effect that led us to discover what purpose a MiddleWare and Reducer should carry on.

Now, it's time to do some testing of our code. But before we proceed, it's good to take an overview of code we've incorporated so far:

Unit Testing

In MVI + Redux Design Pattern, we can Unit Test following:

Reducer: Test out the UI State Management.
MiddleWare: Test out the side-effects.

Reducer

Testing Reducer is straightforward: We assert that for a given current State of UI and an Action supplied, when reduced should churn out the State we expect.

Taking our below Reducer into consideration:

we add test cases like this:

Note that I'm just expecting a certain State for my Reducer to transform to.

MiddleWare

Taking our MiddleWare into consideration:

Testing MiddleWare is tricky: The method process() of MiddleWare does not return anything.

However, we can test what Actions our MiddleWare propagates back to Store. This testing for action itself can be thought of as a side-effect.

So, we create a general purpose MiddleWare that captures Action dispatched from Store:

Then, when creating test class for MiddleWare, we inject the Store manually with ActionCaptureMiddleWare as one of the MiddleWare.

Finally, we assert using ActionCaptureMiddleWare to check if a certain Action is captured or should not be captured Action.

Instrumentation Testing

In this testing, the focus area is Views. Objective for testing UI is to test for a given Test Case, UI should behave as expected.

UI Test in Jetpack Compose

Jetpack Compose testing libraries allows us to Test an individual @Composable.

Library in highlight:

dependencies {
    androidTestImplementation platform('androidx.compose:compose-bom:2023.05.01')
    androidTestImplementation 'androidx.compose.ui:ui-test-junit4'
}

All views in Jetpack Compose are represented as their View Tree. Beside view, there exists a Semantic Tree in parallel with View Tree. This Semantic Tree is useful in Android Framework as it is used by Accessibility Services and Testing frameworks.

Here, each node in this Semantic Tree is a semantic image of same view from View Tree and is represented by SemanticsNodeInteraction.

A SemanticsNodeInteraction is accessible from ComposeContentTestRule.

If you see from it's documentation, ComposeContentTestRule implements SemanticsNodeInteractionsProvider which contains method that provides the SemanticsNodeInteraction.

Now, to get hold of a particular SemanticsNodeInteraction, we must provide a SemanticMatcher to the method onNode() of ComposeContentTestRule.

Upon getting hold of a SemanticsNodeInteraction, then we can perform assertions on it. One example of assertion in SemanticsNodeInteraction is whether the view is actually shown in the UI or not, or if view is clickable, and such.

Here's the Cheat-Sheet for combining SemanticMatchers and Finder methods:

Finally, before start performing testing, we have to populate the @Composable under setContent() method of ComposeContentTestRule.

UI Test in Action

Before we start our test, fetching the UI element should be figured out, remember, @Composable does not use id like XMLs do.

One way is to use hasText(text = ?) : SemanticsMatcher which provides all SemanticsNodeInteraction that matches our supplied text.

fun testCase() {
    rule.apply {

        ...

        onNode(hasText("TEXT_TO_FIND")).apply {
            ... // Perform assertions
        }

    }
}

This works, but is not reliable and can prove cumbersome especially if the supplied text is displayed over more than one @Composable.

A better approach I find useful is to use testTag. testTag is one of the attributes of Modifier. It means, testTag can be added to almost any @Composable, especially the ones we want to test on.

fun testCase() {
    rule.apply {

        ...

        onNodeWithTag(testTag = "SOME_TEST_TAG").apply {
            ... // Perform assertions
        }

    }
}

So, refactored the Screen to use testTag like below:

Now, before implementing the test, here's the formula for performing test on any composable, which makes use of ComposeContentTestRule:

STEP 1: Show the Composable UI under the method setContent of ComposeContentTestRule.

class SomeUITest {

    @get: Rule
    private val rule: ComposeContentTestRule = createComposeRule()

    fun testCase() {
        rule.apply {

            setContent {
                SomeScreen()
            }

            ...

        }
    }

}

STEP 2: Using ComposeContentTestRule, get hold of any SemanticsNodeInteraction using testTag to perform assertions on it.

class SomeUITest {

    @get: Rule
    private val rule: ComposeContentTestRule = createComposeRule()

    fun testCase() {
        rule.apply {

            setContent {
                ...
            }

            view().apply {
                ... // Perform assertions here
            }

        }
    }

    private fun ComposeContentTestRule.view(): SemanticsNodeInteraction =
        onNodeWithTag(testTag = "SOME_EXAMPLE_TAG")

}

With above steps in mind, this is how Test Class for ExampleScreen is implemented:

Notice that I have created another Composable TestScreen. This is done because our ExampleScreen is implemented best when coupled with ExampleViewModel. And when we use MVIViewModel, we get viewState, which get collectAsState(). So anytime ExampleReducer changes the ExampleState, ExampleScreen is going to be recomposed. So wrapped ExampleScreen in another Composable to avoid recomposition and retain the same instance of MVIViewModel.

Takeaways

With MVI + Redux, Unit Testing the logical components:

Reducer can be tested for their role in changing the State of UI.
MiddleWare can be tested for their propagation of Action to Store, giving a view on what are they supposed to propagate.

With Jetpack Compose UI Testing, any @Composable can be tested for correctness, leading to a more bug-free UIs.

With this, I conclude the series.

Here's link to my implementation of all Tutorials:

ritwikjamuar / ComposeSample

Experimentation of screens with Jetpack Compose.

Compose Sample

Experimentation of screens with Jetpack Compose.

Description

This project contains some very basic UI screens (Login for example with just barebones). While UI may be simplistic, most detail to attention has been paid on Design Pattern and Testing (Both Unit & Instrumentation) This project is also my first exposure to Jetpack Compose.

Chapters

License

MIT License
Copyright (c) 2023 Ritwik Jamuar

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright

…

View on GitHub

Thank You!

Jetpack Compose + MVI - Part 1: Side Effects

Ritwik Jamuar — Wed, 24 May 2023 12:30:00 +0000

Previously, I had introduced the mechanics of a MVI + Redux Design Pattern and implemented it as an example.

dev-to-uploads.s3.amazonaws.com

The UI is DaVinci-esque ¬‿¬ but has one problem: Button does nothing.

We would make the click of Button to emulate a REST API Response. This would mean that UI should show progress or some indicator that operation is ongoing.

To emulate a REST API Call, we need a Repository:

fetchSomething() provides a Boolean flag that indicates whether fetching was success or not.

Now, since performing REST API Call is considered side-effect, we create a MiddleWare to handle such side-effect, and here comes ExampleMiddleWare.

Enter `MiddleWare`

To recap, the purpose of MiddleWare is to handle side-effects (or Action that does not make sense to a Reducer). MiddleWare uses store to propagate another Action, whose processing is upto Reducer or another MiddleWare in the Store.

But before we start shaping the MiddleWare for our example, we must add actions that triggers the execution of this MiddleWare and prompts to change the state once the MiddleWare is finished.

This means adding some actions in already existing ExampleAction:

Now, we implement our MiddleWare as below:

Take a look at the method onButtonClicked().

Whenever we receive an intent that Button is clicked, we perform REST API Call.

To make user aware of such, we propagate an action to Show Loading, and when the value is collected, we propagate an action to Hide Loading.

In order for our MiddleWare to work, we must incorporate it to Store in the MVIViewModel:

Because we wish to update our UI whenever Showing or Hiding progress is propagated, we add a field in our State to support that.

Next, we update our Reducer to accommodate for new Actions, i.e. showing and hiding Progress

Back to UI

So, we add a Progress Bar to our screen using LinearProgressIndicator. To add some animating effect, wrapped the LinearProgressIndicator under AnimatedVisibility.

This results in our UI to look like this:

dev-to-uploads.s3.amazonaws.com

Side-Effects revisited

Above is one demonstration of handling REST API Call as side-effect.

But remember, MiddleWare does not have to propagate any action.

Here are some examples that does not propagate anything:

1 : Logging

We want to log our Action and State of our Store for logging and debugging purposes. Logging is again another use case of side-effect, which then translates to MiddleWare as below:

This MiddleWare is general-purpose in nature and can be used with any Store.

2 : Navigation

Navigating to another Activity/Fragment can also be thought of as a side-effect, which can be translated to a MiddleWare as below:

The lambda onNavigate is handled by consumer for them to figure out on what action and state they perform navigation.

Takeaways

The point is, MiddleWare can be thought of as a silo that is designed for a singular or a set of purpose.

Meanwhile Reducer has one role and one role only: For a given Action that is considered state changing, Reducer reduces current State to a new one.

Next post, will be a discussion around Testing.

Thank You!

Jetpack Compose + MVI - Part 0 : Introduction

Ritwik Jamuar — Tue, 23 May 2023 05:36:59 +0000

Introduction

I have been living under rock for some time since the Jetpack Compose has been out in release in July 2021. I have sticked myself to XMLs and View/Data Bindings. Under same time, I started exploring MVI Design Pattern and find it fascinating as it has clear state management of UI.

Fast forward present day, I finally got the zest to try out Jetpack Compose and ride aboard the hype-train.

Let's start with an example:

Resulting the UI to be rendered like this:

I know, DaVinci would rip his Mona Lisa off for my design ¬‿¬
Anyway...

Tour de Design Pattern

I came across a great implementation of MVI Design Pattern coupled with Redux by Adam McNeilly.

AdamMc331 / MVIExample

A sample app showing how to build an app using the MVI architecture pattern.

MVI Example

This application was streamed live on Twitch to demonstrate how to build an application using MVI.

You can find the VOD here for now: https://www.twitch.tv/videos/1036306656

And on YouTube: https://www.youtube.com/watch?v=wTJX_lWdh60

Much of the codebase is documented, but you can expect a blog post coming soon as well.

MVI Diagram

During the stream we created a diagram to understand the flow of data in an MVI application, which you can find here. This may be helpful to review before looking into the codebase:

View on GitHub

To summarise the content of Repository, here are the core concepts:

A State is a representation of UI.

An Action is an intent taken by User from the UI.

A Reducer takes an Action and transform the current State to a new State.

While Reducer is great at handling the state of UI, it is useless when concerned with executing some non-State operations (Performing REST API Call, Logging, Navigate to another Activity/Fragment for examples). These kind of operations can be thought of as a side-effect. And, to handle side-effects, we create an abstraction called MiddleWare:

Here we encounter an unknown entity called Store. Don't you worry, it is what orchestrates the above components involved. To orchestrate the components, Store can leverage Kotlin Coroutines, more precisely StateFlow that can help achieve collecting the state without depending on AndroidX LiveData. Below is the implementation to showcase such:

Well, dispatch() is what triggers every component to receive some Action and perform respective executions.

There's a reason dispatch() chosen to be suspending. You see, there can be myriad of side-effects that are blocking in nature, so it makes sense that MiddleWares can perform blocking operations out-of-the-box.

Lastly, since Store's method dispatch() is a suspending method, it means this method must be executed from a CoroutineContext. There are two options:

Activity: Activity consists of lifecycleScope. But Activity is prone to be destroyed in the event of a configuration change or low memory.
ViewModel: ViewModel consists of viewModelScope. Since ViewModel at least survives the configuration change, it becomes ideal candidate to host the Store.

Now, much of the code for ViewModel can be repetitive for every implementation with Store, so we can simplify this by creating an abstraction:

By default, dispatchActionToStore() will always execute the blocking operations in Main (read UI) Thread. If there's a need that a blocking operation be operated under a certain thread (say IO for REST API Calls, Computation for general purpose processing and such), pass the value of dispatcher as well.

Example Implementation in Action

Since our ExampleScreen only shows one text, so we added this attribute like this:

Our ExampleScreen has two intent from User: Change the Input Text and Handle click of Button.

ExampleReducer changes the ExampleState based on the dispatched ExampleAction from Store.

ExampleViewModel receives events from UI which are then transformed to ExampleAction for dispatching this Action to Store.

ExampleActivity hosts our @Composable ExampleState.

You may ask where is ExampleMiddleWare.kt?

Since the button is not doing anything at the moment (as evident from the ExampleReducer.kt) and there's no UI to showcase such side-effect, it's parked for now.

Stay tuned for the next part.

Thank You!

DEV Community: Ritwik Jamuar

Jetpack Compose + MVI - Part 2: Testing

Unit Testing

Reducer

MiddleWare

Instrumentation Testing

UI Test in Jetpack Compose

UI Test in Action

Takeaways

ritwikjamuar / ComposeSample

Experimentation of screens with Jetpack Compose.

Compose Sample

Description

Chapters

License

Jetpack Compose + MVI - Part 1: Side Effects

Enter MiddleWare

Back to UI

Side-Effects revisited

1 : Logging

2 : Navigation

Takeaways

Jetpack Compose + MVI - Part 0 : Introduction

Introduction

Tour de Design Pattern

AdamMc331 / MVIExample

A sample app showing how to build an app using the MVI architecture pattern.

MVI Example

MVI Diagram

Example Implementation in Action

Enter `MiddleWare`