In the previous post, we discussed how OPTIMUS evolved during our journey. Now that we have a fair sense of what it is capable of doing, lets discuss in more details the implementation of the same. The following diagram explains the architecture of optimus.
We started with some basic requirements in our mind that could make the whole experience of test automation more robust and effortless:
- Framework should understand any connected device/simulators. Users should not bother to configure device details when triggering a test run. They can just connect the devices and let optimus decide what to run where. At the same time if they want, they can take control of which devices should be running tests.
- Every tests should be running in its own container. Each tests starts it’s own appium service, creates a new driver instance, procures a device for it to run, writes to it own log file and kill/close them all at the end. The idea is to have minimal points of failure if at all that are related to infrastructure setup during a test suite run.
- Out of the box support for tests parallelisation. So if you have 50 tests, that you want to run across 5 devices for a faster feedback of the functionality (Distribution) OR run all 50 on all 5 devices to get a comprehensive device coverage of functionality (Fragmentation).
- Support inter-app testing. There are a good number of companies out there that have a unique problem of testing their E2E workflows that require more than one app instances and more than one user. Think of the ola and uber of the world, or any chat applications, or networked gaming apps etc. Optimus has intelligence to provide more than one appium services and related driver instances for such scenarios with just some config changes.
Optimus terminologies – keywords you will notice multiple times henceforth in this blog
- TestFeed – This is the configuration that a test developer needs to share with optimus in order for it to understand the app details and the capabilities needed for the driver instance that would be used.
- SmartBOT – This is an intelligent java object that holds all information needed by a test. Things like, appium service, driver instance for a particular user, device details on which the test is running etc.
With this context, lets understand the different components that make up optimus.
Optimus – The core that does all the heavy lifting
Optimus has been designed as a java application that can do the following:
- Creating a device matrix of all connected devices/emulators – for both iOS and Android
- Managing appium service instance per test – start/stop
- Creating driver instance(s) per test, plural because you need more than one driver instance while working on an inter-app scenario.
- Managing state of devices, whether it is available for a test OR is engaged by a certain test.
Redis – The smart data structure.
Optimus maintains the device matrix and the state of devices using a redis data structure. So we need to have a redis server running all time while the test is running.
OptimusTemplate – The other side of the spectrum (BDD tests)
Optimus template has been written to give users a head start while choosing to use optimus as their core framework. The template gives you a readymade gradle project with an example feature file and it’s implementation through step definitions and page object model pattern.
You can simply download and import the project into your IDE and start writing tests. Nothing beats the simplicity as you can run your very first test across devices out of the box. How cool is that!
Lets understand different components of the template in details.
- testFeed – The configuration file that facilitates the conversation between the tests and the optimus application.
- Cucumber-jvm tests – This is the starting point. You can write nice behaviour descriptions as tests in plain english and implement the same using some java code as step definitions. The driver instance you use is provided by optimus based on the testFeed.
- gradle build script – The template is a gradle project. The build script has tasks to allow running your test suites in either Distributed or Fragmented mode.
- setup/teardown methods – The template has a StartingSteps class where you can find these methods. Using setup the test talks to optimus and gets SmartBOTs registered for itself to use. Using teardown it will de-register the same.
- reports – Nothing beats the awesomeness of nice cucumber-ivm reports with screenshot embedded at point of failure. We have this integrated as we have the BDD style framework.
There is a lot more in the pipeline in coming months. To name a few, expect the following:
- An optimus radiator that gives a live view of which test is running on which device and their pass/fail status to start with.
- A performance monitor to give you a sneak peak of CPU, Memory and battery usage during each test scenario.
- More templates to support writing test in TestNG and JUnit frameworks.
Keep sending us love (aka questions/suggestions/feature requests) on firstname.lastname@example.org.