Flutter, the software development tool that uses the Dart language created by Google, offers an incredible and innovative way to develop both on various mobile platforms (Android and IOS) and, in newer versions, in a more traditional web environment for desktop access.
In the automated test environment E2E*, many technologies have been released for development over the years, both by the Flutter team itself and by external developer communities who have recognised the potential of this software development tool.
Today we want to take a look at a technology originating from the developers, Maestro.
*(End To End, summarising the path from point X to point Y of the application as QA from the user’s point of view).
About automatic testing in Flutter
To decide whether to opt for one technology or another when it comes to automating our application’s test cases, we first need to understand what exactly “automated flutter tests” are.
With a focus on “end to end”, Flutter provides the flutter_test and bdd_widget_test libraries. These are tools that are placed inside the application we develop and have full access to the different widgets, pages and lines of code and give us great control over everything that happens inside the application and are the best solution for unit testing in Flutter.
They also offer compatibility with Cucumber, which makes our tests much more readable for non-technical users thanks to the Gherkin language offered there.
Although all this is offered, one major point must still be taken into account. And that is the extensive knowledge that the tester needs about Flutter, the libraries mentioned and Cucumber. This is usually the biggest mountain to climb in terms of QA in our project.
And this is exactly where Maestro comes into play.
Maestro, effectiveness in simplicity
Written on the basis of Appium, Espresso, UIAutomator and XCTest, among others, the so-called “flow” (the definition of the user’s steps in the application) offers test options that can be executed very easily and immediately anywhere, as they are not part of the project but run externally..
The execution takes place via a .yaml format (a language that is easy to read and write even for people without extensive knowledge of technical terms).
It is designed so that the available commands not only make it easy to recognise each emulator played on the screen without having to link anything, but also so that the various widgets required to complete the desired test route can be found quickly.
To compensate for the lack of compatibility with the POM and Cucumber model, Maestro offers the possibility to organise a structure of nested executions called “nested flows”. With the help of the “runFlow” command, which enables the separate execution of Maestro files when nested correctly, the reuse of code and the ability to organise an easily understandable and manageable structure is made considerably simpler.
Detailed information about Maestro, its advantages and disadvantages
1. Simplicity is too simple
When we look at Maestro, it is immediately recognisable that we have already seen everything, which is both good and bad. We will return to this topic in the next section, as it is perhaps the biggest potential turning point.
Features such as the correct implementation of a Page Object Model, Cucucmber, database connectivity and other advanced additions are not possible with Maestro, at least not in the same way as offered by the other systems.
It is therefore essential to prioritize the complexity of the application to be worked on before choosing the tool, which is very powerful and with very good projection, but also relatively new.
2. Human language
Maestro is quick to learn and thanks to the use of the .yaml language, no advanced knowledge is required. It also offers the ability to execute commands with Javascript, which provides an interesting additional level of depth.
This simple code would already allow us to open an application on a device and simulate a keystroke.
This would be much more complex in the libraries mentioned above.
3. Variety of environments
Not only does it provide assistance with the portability of tests as it is not part of the base project, but the tool recognises both connected devices and simulated emulators from Android Studio (Android devices) and XCode (IOS devices).
In return for this convenience, Maestro loses tools on the tester’s side, as it cannot access things that are available in the base project.
Maestro at WATA Factory
Maestro is a tool whose usefulness and future prediction has been recognised by WATA Factory. The simplicity of test development is something not seen in other tools, and even if the tool is not used in some projects due to their complexity, it is always at the centre of discussions about automated testing in future Flutter applications.
