Mobile Testing Practices

26 Dec 2020

Originally posted on Talkdesk Engineering Blog.

This article is very straightforward: I just wanted to share some guidelines we follow at Talkdesk’s Mobile team regarding tests. I’ve been working with TDD in the whole past year and this approach helped us to be very successful both in Android and iOS. We’ve achieved a great speed to add features and make changes. As time goes by, the speed does not decrease, which is the main purpose of software architecture. We do it in a clean way, where we work separately in the domain, presentation, and data, always abstracting dependencies, which makes us able to properly divide the work in order to deliver smaller pieces of code without big conflicts.  I will use Swift in the examples, but it could be Kotlin though since we basically test in the same way.

Name tests by scenarios

Tests are documentation, so it’s very important they explain well what is being tested. As we know, naming classes and functions is one of the hardest things in computer science and naming tests wouldn’t be easier. The practice here is to represent the scenario (a specific case of the user-story written in a non-technical language). In our team, we use BDD with specification by example to define our acceptance criteria and it guides us through the whole development cycle, starting with a first refinement with the product team and other stakeholders. In another occasion, we do a technical refinement, where we add tech approaches - technical steps specifying what is necessary to accomplish that work with the purpose of reducing risks for the effort estimation - to the tickets and split them out as necessary to both reduce risks and parallelize the implementation, if possible. In our QA process, that could be done by a developer or any other person, those scenarios are checked as well as UI/UX aspects, and the user story is finally good to go.

Example: Navigating from Account to Home screen, BDD-way

First scenario: Correct account name input
Given I am in the account screen
When I type “talkdesk” in the accounting field
And I press the Next button
Then I see a loading indicator
And I see the Home screen

The scenario represents a behavior from a user’s perspective, so it’s written in a functional way. Chances are that many tests will be necessary to cover this behavior, usually in different layers of the software. In other words, to satisfy the acceptance criteria, you must code all the small behaviors/states contained in it, such as account name validation, user interaction, and navigation. You will cover them in isolation with unit tests. At Talkdesk, we always start from the Domain layer, so we will start from the account name validation, which contains the business logic needed here.