
And Selenide brings us the support of desktop web browsers thanks to Selenium WebDriver. Appium was an obvious choice due to its long list of supported platforms. TestUI is based on Appium and Selenide, two of the most powerful, all-round test automation frameworks. The main focus is on mobile testing with additional desktop browser support, but it can be easily used the other way around, for desktop browser testing with some additional mobile testing.
Cleaner code for interaction with elements. Some simple but expandable parallelisation. But what if you started with Android devices and then the system you’re testing starts to support iOS as well? Or what if you’re using Appium, but want to do something on a desktop browser in the middle of the test? For example, access that versatile admin panel to check if the data you created from the mobile device is correctly saved in the database? These are the kind of issues that inspired us to create our own framework: TestUI. It’s easy if you know that you will only need to automate tests on Chrome, or only on real iOS devices. The second big issue is platform support. You need proper project structure for scalability, improved classes for interaction with elements, some multithreading to run the tests on multiple devices, servers and emulators to automatically start at the beginning and so on.
In most cases you don’t just create one test scenario for one device and call it a day. But which one to choose?Īt TestDevLab we are working with mobile and desktop web UI test automation on a daily basis and there are two problems that we constantly have to deal with. Just to name a few – Selenium, Puppeteer, Appium, Calabash, Robotium.
There are so many test automation tools available on the market.