Don’t judge a UI by its cover!

In the world of Android applications, Jetpack is the latest practice for Compose UI development. Although it’s declarative, it sometimes gets complicated because everything you’ve designed is really all code. Additionally, we have a lot of state to maintain in Composable. Hence, writing test cases for UI becomes very important and important.

In this article, we’ll start writing tests for our composable. We’ll see what all the APIs are available to do this and how we can think of use cases on our UI so that we can test them properly.

We will cover the topic in the following order

• Creating a composable with inputs and actions
• setting up test environment
• writing test cases

So let’s get started!

First, let’s create a composable that looks like the image below.

Our composable shown above has three states.

1. initial state:Once we start our activity, the first image will be our starting position start copying is kept as default text until we do any click action on it copy button. The TextField remains empty with the input as the label.
2. Invalid State: User can enter any input text but we are checking it for int type. So, if the input is not a number and the user clicks copy button then we will show Invalid entry In place of start copying label.
3. valid status: If user enters a number then we will show the entered input with text Counter = $input click on copy button.

So let’s get composable quickly because making composable is not the main focus area of ​​this article.

We’ll have a text at the top, then a text input field and a button, all wrapped under the column.

Previewing composable, we will see it as below.

cold. We are now ready with our UI. Let’s set up its test environment now.

By default we are provided with required dependencies when we build our project. In case they don’t exist in your build.gradle Then add them.

androidTestImplementation 'androidx.test.ext:junit:1.1.3'
androidTestImplementation "androidx.compose.ui:ui-test-junit4:$compose_version"

We should also make sure we set our test runner as AndroidJUnitRunner in default configuration build.gradle, it is important because AndroidJUnitRunner Please help us to do unit testing under Android environment.

defaultConfig {
...
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
...
}

Well. Let’s now create a test class for our composable.

Remember that this class has to be created under androidTest folder and not in testing folder.

Once our class is created, we annotate it RunWith(AndroidJUnit4::class) To indicate that the tests are to be run with the Android JUnit runner and not with the regular JUnit runner.

Now we need to create a compose rule object which is the main key in testing our composable. createComposeRule Essential because it gives us access to our composable components. With the help of this, we can also test our composable in isolation.

If we want to reference our activity in test then we can create createAndroidComposeRule<MainActivity>(),

Then we set our composable as the material for our compose rule.

So our test class looks like this.

Wow! Time to put everything into action. Let’s test whether the three states we mentioned are shown correctly during UI creation when the specific action is performed on clicking the copy button.

Test Case 1: Initialization

First, we just verify whether all our views are present in the default state.

Let’s take a quick look at how we access our composable components here.

line 3: with composeTestRule.onNodeWithTag Indicates whether a component with the TEST tag as “Counter Display” is present.

line 4: with composeTestRule.onNodeWithTag Indicates whether a component with the test tag as “input” exists.

line 5: with composeTestRule.onNodeWithText Indicates whether a component with the text “Start copying” exists.

onNodeWithText And onNodeWithTag Here are of the same purpose but we can use either. we can set a testTag to our modifier so that we can identify the component when testing.

The result of running the test will be as follows:

Test Case 2: Invalid State

If we click on copy button whereas Input is empty display text must be Invalid entry. This is because our helper function returns this text when a number format exception occurs.

Line 3: First we identify our idea with text Copy On this. Once identified, we perform a click action on it. now onClick The block of our buttons will be called.

Line 5: We know that if the input is invalid it will be displayed as an invalid entry. So we first identify our view with the test tag “counter display” where the final output will be displayed. Then we claim whether the text on it is “invalid entry”.

The result of running the test will be as follows.

Test Case 3: Valid condition

Now, we will test if we input an integer correctly and on click of the button, do we get the text as “counter=1” on the “display counter” text component?

The result of running the test will be as follows.

The result of running all three test cases together will be as follows.

Great! magnificent! We have finally tested our composables for all different scenarios and verified that they behave as expected. Now we are more confident on our UI part.

You can play with writing more scenarios and tests like this. It will be fun. Getting this far would be enough to get started on testing compostables. Once we get good at testing simple ones we will test more complex UIs.

See the full code for this article below.

If you want to read about testing the different layers of your app. Check the below link: