Developing a high-performance app that works on any device or platform, keeping in mind the constant evolution and update of mobile OS, and the visual trends for the user interface, is critical. There are agile development methods, thus we need to back them up with an efficient, quick and trustworthy test technique. That is why mobile app testing is automated, and we have a little recipe to do that.
The ingredients are:
* Cucumber (BDD) * Appium (Mobile Driver) * Emulator, Device or Simulator * A little bit of QA Engineering
To start with, we need to use Cucumber to give consistency to the recipe. It is a neat tool that developers can use to test their work in a mobile context, as well. Basically, Cucumber can run automated acceptance tests written in a behavior-driven development (BDD) and it is available for most platforms/programming languages. One of the best parts of Cucumber is that it also provides documentation and feature specification for mobile app testing and it allows test scripts to be written on a lot of programming languages following an existing or own design. That makes Cucumber one of the most important ingredients of this salad.
The taste comes with the Appium, the open source test automation tool.
It allows us to run the test cases on real devices, emulators and simulators, so we will need one of those. Focused on the 2 most popular platforms, (iOS/Android) the Appium philosophy is to reuse the code between them; that way, you can use the same framework, and the same base code to test both, lowering cost, maintenance time and design complexity. In addition, you can choose the language you want to write your test in. It doesn’t dictate the language or framework to be used.
But... How does Appium do it? Well, this is a simple question with a simple answer: it has a server where Selenium WebDriver is implemented and it allows our app to act like a web app where the DOM is represented by View hierarchy.
Therefore, this server basically performs the following actions:
Receive connection from client Listen to commands Execute commands Return the command execution status
To finish with it we need to add a little bit of QA Engineering. It’s a QA Engineer task to be the chef on this salad, as he/she is going to be the one to decide the proportion of the ingredients and the way to mix them.
As a personal recommendation, the best way to work with these tools, is having consistent and really dynamic Cucumber features, adapting those as much as you can. Using the same step to test the same behavior is a way to abstract the test cases in actions and responsibilities. Also a dynamic implementation of Cucumber Steps saves a lot of code and complexity. Another advice about Cucumber, you should use a simple and understandable name for the steps, any person able to read the steps should notice the essence of the test case. Keeping the actions representing by steps, you can reuse them, and write a test in a matter of minutes.
Simple Steps Definitions: A good way to follow this advice is programming an organized back-end code to implement all the complex logic. By programming objects oriented to delegating functionalities and responsibilities using an existing or an own Design Pattern, you can design an expected flow and a lot of mechanisms to validate it.
When talking about useful logs, creating a personal logger is amazing, you can perform prints to know what is happening on the flow, debug and find the causes on a failed scenario. The logs should be clear and specific, and must be an assistant for you when you are in trouble.
As a conclusion, Cucumber together with one of the best test automation frameworks today – Appium – is a great combination and can help to you automate testing of your apps, write nicely documented specifications and make clarity for test execution.