Looking to boost test coverage on a legacy system but don't know where to start? With a background in mobile app development, Douglas Hoskins, Head of Mobile at Future Platforms shares his insight on how you can maximize your efforts and engender greater confidence in your system by turning to the lightweight alternative that is subcutaneous testing.
Automated testing through an app's UI can be a tempting way in when you're first looking to boost test coverage on a legacy system, but as the
Test Pyramid tells us, UI tests should be our last resort; they are the hardest to write, take the longest to run, and are the most likely to break unexpectedly. In fact, the latest generation of native UI test tools on iOS and Android have improved dramatically, meaning that some of these issues are less severe than they once were. However, the general principle still holds.
In this article, we will show how subcutaneous tests provide a lightweight alternative to UI tests. They are easier to write and run, yet can still exercise all of your app's key user journeys. We will also see how a suite of subcutaneous tests can serve to document your system, providing value to others beyond your technical team.
The term 'subcutaneous tests' comes from Martin Fowler, meaning 'a test that operates just under the UI of an application.' These are tests which span the interactions between the
UI and service layers of your app. Essentially, your tests are simulating the journey a user would take through your app, but invoking the methods directly on the code behind the view, rather than interacting through the view itself with a UI test.
Within these tests, your UI controllers should be 'mocked'. This can be done manually, or preferably using a mocking framework suitable for your platform - Mockito for Java is a favourite of mine. The idea is then to verify the correct interactions on these mocks, ensuring the correct methods are invoked, and all the data you expect is passed to your UI.
Why is this effective? When we write tests on classes in our codebase, we are actually testing the interfaces of those classes and ensuring they behave in the way we want and expect. Therefore, to maximise your testing efforts, identify the interfaces that you really care about and concentrate on those.
In a UI-driven environment like a mobile app, the interface between the UI and the app logic is certainly something we care about. Subcutaneous testing, therefore, really makes sense in this context.
This style of testing can provide great value, with tests being both straightforward to write and fast to execute. Using the well-known Page Object Model technique, screens within your app exist as objects within your test code, with the facility to perform any operation a user could perform. These objects can be reused throughout your test code base. Once you have established page objects for your app's key screens, tests become even easier to write and maintain.
Such tests also tend to exercise a great deal of your application code, doing so in essentially the same way that your app users would be doing it. They can be an effective way of achieving a
good level of test coverage, casting a wide net and ensuring your system is integrated correctly.
When an issue is raised on your app that clearly relates to business logic, a subcutaneous test should be in any developer's toolkit when fixing it. The user journey through the app, as reported by the tester, is replicated in the test. This test can then be run quickly by the developer to verify a solution, rather than rebuilding the app every time. And the subcutaneous test then lives within your test suite, ensuring that bug will never reappear.
An extensive suite of these tests provides benefits beyond preventing regressions; written carefully, they can also act as living documentation of your system's capabilities. If tests are well named, and written in a Cucumber-inspired 'Given/When/Then' style, they can provide value to product owners, project managers, developers and testers alike.
Subcutaneous tests can deliver high value in terms of confidence in your system, at a lower cost than automated UI-level tests. Consider making them part of the 'definition of done' of your user stories.