Role of Local Databases in Android App Testing

Hi! I am Katya, a member of the START mobile testing team. I will discuss the importance of local databases in apps and why it’s crucial to examine them during testing.

Mobile applications bring various conveniences to our lives, something we’ve grown accustomed to. Imagine this scenario: you’re flying on vacation and have planned ahead for your in-flight entertainment. You open your favorite app and download movies and TV series. While traveling, you might not have Internet access, but you can still watch the content you’ve downloaded. But how does this work from a technical perspective?

The content we download is stored in the app’s folder on the device, while the information necessary for the app to function is stored in the local database (DB). This isn’t always just for offline use; it depends on the app’s features and purpose.

As we’ve established, a local DB is a database located on a single device. Each device will have its own DB, even if it’s used by the same person.

Here are some instances when a local DB can be useful during mobile app testing:

• A successful data saving case. For instance, if a task requires preserving information that should be accessible as long as the app is installed, we verify during testing that the data has been preserved;
• For error localization. The task may specify that the data in the local DB can be altered. If the saved data in the app changes, but reverts to old data after reopening the app. In such a case, we can open the local DB to check if the data has been preserved;
• For migration testing. Typically, manual testers verify migration by updating the app to a new version. We can check if new fields have been added to the relevant DB and if the app is functioning normally;
• For testing offline mode. In this case, it’s important to remember that we’ll be using data from the local DB for offline mode (if implemented in the app). If any data is missing, we can cross-check with the DB to see if we missed saving anything.

It’s worth noting that accessing the local DB in a released build app can be quite challenging. You would need a rooted device and a lot of desire.

Let me share an example where this knowledge proved useful at work. Every movie and TV series has licensing rights and an expiration date. These rights also extend to downloaded content. Sometimes these rights aren’t renewed, and it’s necessary for clients to manage this state for user-downloaded content. During task testing, we checked in the local DB that the required date was being saved and that it matched the backend response, rather than recording the download date, for instance.

Besides the logic, we also had to test the user interface (UI) part. Surely, the expiration date of licensing rights is set in the admin panel and comes from the backend, but changing the date and downloading the product each time just to check the UI part is time-consuming. So, we can change the product’s date in the local DB and test the UI part with less effort.

Our developers have made our job easier by including download actions in the debug menu, for which we are very grateful. However, I believe it’s beneficial to understand how this works.

Using the Android as an example, I’ll show you how to view data in a local DB.

We’ll need a device/emulator with an API level of 26 (Android 8) or higher, a debug build, and Android Studio. To avoid violating the NDA, I’ve downloaded an open-source project from Google to demonstrate the capabilities of Database Inspector. You can also clone this project using this link.

Database Inspector is currently located in the App Inspection plugin. To open it, navigate to Android Studio -> View -> Tool Windows -> App Inspection or click on the bottom panel. I have a debug APK installed on an emulator with API 34.

When we open App Inspection, Database Inspector is opened by default. We locate sunflowers-db and see three tables upon opening it. If we expand these tables, we can see what fields each table has and what type of data they support.

By double-clicking, we can view the data in each table. This data is displayed in the app on the corresponding screen.

We’ve confirmed that the data in the app matches the data in the DB. Now, let’s suppose we want to see how the app’s UI would change if the name was longer. We’ll edit the “name” field for Apple, for example, to “The longest name like apple.” Here’s what we ended up with:

The sorting function worked, but the full title isn’t displayed. This gives us a reason to discuss with the team about limiting the number of characters in plant names.

Database Inspector also supports SQL queries. We open the query window and compose the necessary query. It’s convenient that the studio provides prompts and assistance with this.

This is useful if you have a lot of data in your local DB and need to find something specific.

I’ve covered the main aspects of working with the Database Inspector tool. Much depends on your project and tasks, but I hope this knowledge will be enough for you to familiarize yourself with it and start using it in your work.

#mobiletesting #Android #QA #apptesting #database