Testing and Debugging Compose Apps

Programming is a very creative process. Implementing great-looking user interfaces (UIs) with slick animations is pure fun with Jetpack Compose. However, making an outstanding app involves more than just writing code. Testing and debugging are equally important because no matter how carefully you design and implement your app, bugs and glitches are inevitable, at least in non-trivial programs. Yet there is nothing to fear, as there are powerful tools you can wield to check whether your code is acting as intended.

This chapter introduces you to these tools. The main sections included are listed here:

• Setting up and writing tests
• Understanding semantics
• Debugging Compose apps

In the first main section, I will walk you through important terms and techniques regarding testing. We will set up the infrastructure, write a simple unit test, and then turn to Compose specifics—for example, createComposeRule() and createAndroidComposeRule...

Technical requirements

Please refer to the Technical requirements section of Chapter 1, Building Your First Compose App, for information about how to install and set up Android Studio, as well as how to get the sample apps. This chapter covers the TestingAndDebuggingDemo sample.

Setting up and writing tests

As a software developer, you probably enjoy writing code. Seeing an app gain functionality feels very rewarding, probably more than writing tests—or worse, finding bugs—yet testing and debugging are essential. Eventually, your code will contain bugs, because all non-trivial programs do. To make your developer life easier, you need to familiarize yourself with writing tests and debugging your own and others’ code. Testing an app has various facets that correspond to different types of tests, as outlined here:

• Unit test: You need to make sure that the business logic works as expected. This, for example, means that formulas and calculations always produce correct results.
• Integration tests: Are all building blocks of the app properly integrated? Depending on what the app does, this may include accessing remote services, talking to a database, or reading and writing files on the device.
• UI tests: Is the UI accurate? Are...

Understanding semantics

Unlike the traditional view system, Jetpack Compose does not use references to identify individual UI elements. Please remember that such references are needed in an imperative approach to modify the component tree during runtime. But this is not how Compose works—instead, we declare how the UI should look based on state. Yet, to test if a particular composable looks and behaves as expected, we need to find it among all other children of a Compose hierarchy.

This is where the semantics tree comes into play. As the name implies, semantics give meaning to a UI element or element hierarchies. The semantics tree is generated alongside the UI hierarchy, which it describes using attributes such as Role, Text, and Actions. It is used for accessibility and testing.

In the previous section, I showed you a simple test case that checks if a button text matches a given string. Here is another test case. testLetterAfterButtonClickIsB() performs a click on the...

Debugging Compose apps

The title of this section, Debugging Compose apps, may indicate major differences to debugging traditional View-based apps. Fortunately, this is not the case. On Android, all composable hierarchies are wrapped inside androidx.compose.ui.platform.ComposeView. This happens indirectly if you invoke the setContent {} extension function of ComponentActivity or if you deliberately include a composable hierarchy inside a layout (see Chapter 9, Exploring Interoperability APIs). Either way, in the end, ComposeView is displayed on screen—for example, inside an Activity or a Fragment. Therefore, all aspects regarding the basic building blocks of an Android app (activity, fragment, service, broadcast receiver, intent, and content provider) remain the same.

Of course, any UI framework advocates specific debugging habits. For example, the View system requires watching for null references. Also, you need to make sure that changes in state reliably trigger updates...

Summary

In this chapter, we looked at important terms and techniques regarding testing. In the first main section, we set up the infrastructure, wrote and ran a simple unit test locally on the development machine, and then turned to Compose specifics. I introduced you to createComposeRule() and createAndroidComposeRule().

Next, we looked at how composable functions are found in a Compose hierarchy, and why making your app accessible also helps in writing better tests. You also learned about actions and assertions. Finally, we added custom entries to the semantics tree.

The final main section explained how to debug a Compose app. We revisited the semantics tree, and I showed you how to take advantage of InspectorInfo and InspectorValueInfo to debug and test custom modifiers.

Android has always embraced different form factors and device classes. Wouldn’t it be great to bring your Jetpack Compose apps to tables and foldables? In Chapter 11, Developing for Different Form...

Further reading

• This book assumes a basic understanding of how to test Android apps. To learn more, please refer to Test apps on Android at https://developer.android.com/training/testing.
• JUnit in Action by Catalin Tudose (Manning Publications, 2020, ISBN 978-1617297045) is a thorough introduction to the latest version of the JUnit testing framework.
• If you want to learn more about test automation, you may want to look at Complete Guide to Test Automation: Techniques, Practices, and Patterns for Building and Maintaining Effective Software Projects by Arnon Axelrod (Apress, 2018, ISBN 978-1484238318).
• To get an insight into the test pyramid metaphor, you may want to refer to The Practical Test Pyramid by Ham Vocke, available at https://martinfowler.com/articles/practical-test-pyramid.html.

Questions

1. What is the difference between unit tests and instrumented tests? In which scenarios do you use both?
2. What is the general layout of test classes, and which annotations are typically involved?
3. What is a semantics tree? How can you contribute to it?