Test Nexus — Kitchen Sink for Fast and Reliable Mobile App Testing

Cross-Platform Technique — Shortcut for Setting Up App State ➡️ Faster and More Reliable Appium Tests

In a previous post, we used the deep linking technique for expediting and stabilizing our mobile app testing. Let’s consider another simple and straightforward approach, which involves UI automation using Appium.

It’s called the Test Nexus technique. What’s a Test Nexus? It’s basically a kitchen sink view in our app which contains links to a variety of other locations in our app, that come with attached state. It’s a laundry list of different test components. It’s a special initial app view that only gets loaded during app testing.

The main idea is that on this one view there’s a bunch of buttons. Each button takes us to a different place in the application. So rather than tapping through the app like a regular user, we can just tap one button and get transported magically to a distant place in our app that might have taken a long time to get to if we were a regular user. The Test Nexus is only available in the test build, it should never be shipped to customers.

We can have a link that says Logged-In Home, or one that reads Cart With 10 Items. Tapping either of those links would trigger the app to take us to the appropriate view, with the appropriate state. This does mean the app developer would need to hook the links up to any necessary logic.

The advantage of this approach is that it is cross-platform, and easy enough for the Appium test author to simply find the right button and click on it, saving a lot of time in the process.

The real value of the Test Nexus becomes clear when we realize that we can have buttons which not only take us somewhere new, but which also trigger various kinds of setup to happen for us automatically, that would normally take a lot of UI interaction.

The Test Nexus requires only standard Selenium or Appium element searches and interactions from the test code perspective. Test Nexus portals are just buttons, which can be interacted with easily by using the standard API.

Pros ➕ and Cons ➖

Pros:

1. One great thing is that from a test author perspective we’re just dealing with tapping buttons using the standard Appium API, which makes using the Test Nexus dead simple for the automation.
2. The Test Nexus is also really easy to expand. We just keep making the Nexus view longer, adding more buttons.
3. The Test Nexus approach is a quick and efficient way to cut out lots of time setting up app state. Just tap a button and we’re there.

Cons:

1. One drawback of this approach is that we’ll need a test-only version of the app. We don’t want to ship the Test Nexus to users.
2. The other main drawback is that the Test Nexus functionality needs to be built by developers. Without the source code and ability to modify it, test authors can’t implement this on their own.

∴ In conclusion, let’s take a quick glance at real life examples by Jon Lipps and Wim Selles. These apps exhibit how we can implement the kitchen sink technique and tangibly put it to work as mobile testers.

Wishing you happy and speedy testing! Stay tuned for upcoming posts about making mobile test suites faster, more reliable, and less flaky.

I welcome any comments and contributions to the subject. Connect with me on LinkedIn, X , GitHub, or Insta.