Selenium 4 was released last year with new features and improvements. Being a selenium user it is high time to adapt to writing our automated tests in selenium 4 way. Here are some key questions we can ask before migrating selenium 3 tests to selenium 4.

-  What does it take to migrate automated tests written using selenium 3 to selenium 4?

-  Is it simple enough to start with when we have lots and lots of tests written using selenium 3?

-  Is there any additional prerequisite or dependencies we may need to keep in mind?

-  What are the challenges, errors and deprecation messages we may come across?

Migrating tests is a painful and time consuming process if not planned well. Thanks to the flexible architecture of selenium and detailed documentations, the process is actually simple if you are using any one of the officially supported client language language binding. In this presentation we are going to walk you all through the entire process of migrating selenium tests from 3 to 4 with key focus on the changes and new implementations. 

                 Appium has came long way with the evaluation of different drivers. The journey of providing support for blackbox testing to graybox is just phenomenal. We face many real time issues while testing our apps right from flaky tests to areas which cannot be tested with blackbox testing approach. In android platform, UI automator driver has matured level but we cannot still test areas which needs access to the application code. Luckily we have a bridge now which can help us to use both black box and graybox testing in the same time, yes we are taking about Espresso driver. In this session we will be covering some of the interesting aspects of both the drivers (UIAutomartor2 and Espresso) and explore in detail the pros and cons of both via a demonstration.

Problem Statement: While testing a native IOT application, we could figure it out the following issues using blackbox automation approach.

• The validation of the style attributes (for example the change in colour of an element based on event)
• Testing notifications
• Synchronization of the script due frequent UI element update via async API calls
• Testing two applications together one release app and another debug app
• Need of accessing of native components of  Android

Solution: After doing a close review and analysis we could realise that using just one appium driver will not be enough to overcome all the issues listed above. Carefully selecting the best of UIAutomator2 and Espresso driver we could get the desired output and found the perfect duo for our use case. In this presentation we will be demonstrating the same how we have done the end to end testing of an IOT application (M2M communication) using appium UIAutomator2 and Espresso drivers.