TESTEROPS

A pragmatic approach to QA and OPS

Maestro

One of the most challenging problems faced by me (and I think so many others) is mobile automation. If I have to compare web with mobile, the latter is much harder to set up, maintain and target for due to varied number of reasons – the device and OS fragmentation, the absence of good libraries for automation (sans Appium which is even a medium best to be honest).

One of the key things that as a test automation professional, I see is that a lot of emphasis is given on writing code – whereas the major chunk of the work needs to be done before hand – at the analysis and the planning phase – but I think so that is a separate discussion and would require a separate post ( or multiple separate posts).

My Tryst with Maestro

I like to read. I like to read a lot – but not in the form of books. I like a quick read – blog, engineering blog, e-paper, vlogs etc – I consume information in all forms. Thats why I think the app Inshorts is one of the oldest apps that I’ve on my phone – probably apart from Whatsapp. It gives me quick roundabout of news all round the world in short titbits. I like it that way.

Now that is when one day I say an weekly roundabout of curated articles that Medium sends me and when going through it, I came across this new tool – which was named Maestro and aimed at minimising the pain of test automation for mobile.

Umm. Interesting. So I read the whole article and also went through their documentation. Now I thought that I’ll maybe try this in my free time and that never came. Its been now more than a year so I thought to come back and now try to work with Maestro and maybe Appium as well.

Why Maestro

So this is the most basic and I think so the most common question that comes to people is that – why Maestro? Frankly I do not have answers yet. As much as I want to compare it with others – I have not done that and I’d rather not comment on the comparisons. However there are some features that the team behind Maestro have learnt from its earlier predecessors (and/or competitors) like Espresso, Appium etc.

  • Flakiness is tolerated by design. In Maestro, the unstable nature of mobile apps and devices is accommodated and UI elements are deconstructed to counter the instability.
  • No need to call sleep() repeatedly in your tests. The Maestro knows that loading the content may take some time (for example: over the network) and waits for it automatically (but not too long).
  • There is no need to compile anything because tests are interpreted. As your test files change, Maestro automatically reruns them.
  • Maestro supports native (Android and iOS) and cross-platform mobile platforms (Flutter and React Native).
  • Ease of low code. You can say that Maestro relies on yaml files and commands to perform the set of actions which tends to make the actions less code-heavy that its earlier predecessors like XCUITest, Espresso etc.

So looking at these, its imperative for someone like me who loves to experiment to delve into it and try it out. Over the weekend, I tried my hands around it to play around with it for some time and see how it feels. However, before directly jumping into the code, I’ll try to take a step back and start from scratch – which is what I did for these experiments.

Pre-Set Up Stuff

Now, this is what I hate about most tool-focussed tutorials. They assume that the person reading the tutorial has already done the pre-requisite for installing the tutorial – or in most cases, they would just mention that you’d need to install this and that – For eg – in most Playwright tutorials, they will tell you that you’d need to install nodejs in your system.

However, will that installation faces issues or challenges, that becomes out of scope of the tutorial. And if someone is not able to install nodejs, then they’ll fail at the first step for Playwright and this is when a lot of folk leave it as it is.

So, I’ll start with the most basic thing – my system – what it is and what do I need to do before I even think of installing Maestro.

System

The system that I’m using is a Macintosh ( or MacOS) system , which has the M3 Pro processor which came out in late 2023 I think. Don’t ask me why Mac – because at this point I feel like I’m biased in answering. I’ve been using Mac systems since last 9 years and I don’t think so that any Windows machine can compete with Mac when it comes to power and UX.

I’ll just add my system screenshot as well.

Why system? Because when you’re setting the Environment variables, you need to set them using terminal (in most cases) and it’s very imperative for me, technically to know which shell I’m using in which system.

Because I’m using a Mac system, post Catalina ( version of MacOS), so its important to know that the default shell has now changed from bash to zsh. How it effects things?

For once, if you’re installing Java or Android, then the env variables that you’d need to set , has to be done in the ~./zprofile file instead of the ~./bash_profile , which is where I’ve seen a lot of folks do the wrong thing.

If you see the screenshot below ( ignore the red error) – you’ll see a couple of things

  1. ANDROID HOME is not set. Which means that even if you’ve downloaded ANDROID or ANDROID studio, chances are that libraries like Maestro wouldn’t be able to find it. I’d recommend reading about why do we use env variables from the Google if you’re missing the idea on this one. One link can be this.
  2. HOME directory path – Its just for a person to which which is the home directory in a Mac machine. my user name is shrijanki so the path would be /Users/shrijanki.
  3. SHELL name – if you’d like to know which is the default shell in Mac, just run this command echo $SHELL and it’ll print out something – if its /bin/zsh , then your default shell is zsh and not bash.

Installations Required

These are the required libraries/files/software that you’d need even before installing Maestro. Let’s start with the first one – Android Studio

We’d Android Studio because it makes it breeze for someone to install or debug an apk, develop Android apps or even set up your emulators.

Just google Download Android Studio and from the first link in the search – download the Android Studio file – the current version as of today ( 20/02/24) is Hedgehog.

Once downloaded, just install it and follow the due process of installing all the dependencies. Once done, now its time to set the ANDROID HOME environment variable.

Follow these steps

  1. Open a terminal and type -> nano ~/.zshrc or nano ~/.zprofile
  2. Copy paste the below four lines and replace {username} with whatever pwd name you’ve. Above I’ve given step to find the pwd (present working directory)
    export ANDROID_HOME=/Users/{username}/Library/Android/sdk
	export PATH=$ANDROID_HOME/platform-tools:$PATH
	export PATH=$ANDROID_HOME/tools:$PATH
	export PATH=$ANDROID_HOME/tools/bin:$PATH

After doing these, if you’d type echo $ANDROID_HOME in your terminal, then it should show you the path that you’ve provided for ANDROID_HOME.

Next is to download Xcode. Almost all the applications running in Mac machines benefit from Xcode installations and its different extensions. So just head over to the Apple Appstore, search for Xcode and download it. It’s a heavy download and will take some time to finish.

Some more misc things

By the time Xcode is downloading and getting installed, its a good idea to do these two things –

  1. Create a new emulator in Android Studio.
  2. Locate and work with adb – Android Debug Bridge.

To create and manage AVD ( Android Virtual Device), this nice tutorial would be enough get started.

Now to work with adb, you first need to locate it. The location now a days is inside the platform-tools directory. So it should be somewhere in

/Users/{username}/Library/Android/sdk/platform-tools

Open a terminal here and do ./adb. It should print a whole document of the various options and different flags that you can use.

Couple of commands that you need to know

  • List the number of connected devices ( emulators and real devices) -> ./adb devices
  • Select a device from a list of devices -> ./adb -s "device_id
  • Install an apk on an emulator -> ./adb -s "emulator-5554" install "absolute path of the apk file"
  • List of packages installed in a device -> ./adb -s emulator-5554 shell pm list packages -f
  • List of packages installed in a device containing word test -> ./adb -s emulator-5554 shell pm list packages -f | grep test

In the next step, we’ll try to install Maestro and work on creating a sample script.