What if you had to create a custom driver for your use case in your project and with Appium 1.0 it was not possible without making any code changes to the actual appium code base. This would lead us to maintain a fork and make our required changes. Which in turn is overkill as we have to always keep up with upstream. 

With Appium 2.0 architecture we can create drivers and plugins for our unique needs. At this talk, we will talk about Appium 2.0 architecture, how to make custom Appium drivers and what other breaking changes we brought in Appium 2.0.

As Web Components gain more traction in the web to help websites become more performant it has created a bit of a blind spot on how to test these new features.

In this talk, David will walk you through what Web Components are and how they are benefiting the web as we move forward. He will then walk you through how we can go about testing these and how, while well-meaning, other frameworks are making things a little harder to test. He will also go through some of the performance aspects of the Web Components and how this translates to your tests.

Multiple web frameworks have been invented to simplify the web development process, increase flexibility and reduce time to market. React js is one among them which has a significant growth in recent times. As these web frameworks are being evolved rapidly, we should also adopt tools that provide sophisticated functionality to test them. Even though Selenium is a dominator in the web automation space, it also has some downsides when automating some of the complex web apps that are built using styled-components which results in generating dynamic CSS classes that keep on changing for every UI build.

Automating such scenarios becomes problematic when the CSS classes are ever-changing. Under such circumstances, ReactWebdriver provides a out of box locators that can be used to locate web elements using React js component name, props and state.

Selenium WebDriver is a library that allows controlling web browsers (e.g., Chrome, Firefox, Edge, etc.) programmatically using different languages (such as Java, JavaScript, Python, Ruby, or C#). Internally, Selenium WebDriver uses the native support implemented by each browser to carry out the automation process. For this reason, we need to place a component called driver (e.g., chromedriver, geckodriver, msedgedriver, etc.) between the script using the Selenium WebDriver API and the browser. WebDriverManager is an open-source Java library that carries out the management (i.e., download, setup, and maintenance) of the drivers required by Selenium WebDriver in a fully automated manner. In addition, as of version 5, WebDriverManager provides other relevant features, such as discovering browsers installed in the local system and building WebDriver objects, and running browsers in Docker containers seamlessly. The last feature added to WebDriverManager is related to log gathering. As of version 5.2.0, WebDriverManager provides seamless integration with BrowserWatcher, an open-source browser extension that allows gathering the browser console programmatically (even for Firefox, which was not possible to date). 

Selenium is an amazing library for UI Automation. However, using it in a project needs a proper test design, a good approach and the best framework. I have listed some of the challenges that most people face during automation and will also brief on how we can solve those problems with effective design and approach.

Key Challenges :

1. Field level validations on a form containing several fields. (Many people will ignore these tests in automation as it may increase the number of lines of code and number of tests. Maintaining them is a difficult task)

2. Verifying the state of the web element before operating on it. (It is imperative to check whether a web element is present or visible or clickable or needs a scroll to operate. Also, different elements need different explicit wait times. Most probably we will have number of methods like waitForElementToBeClickable, waitForElementToBeVisible. This again results in increased lines of code. )

3. Assertion of multiple components on a page. (Sometimes we want to validate several items on a page and writing methods like getTitle, isCompanyLogoPresent, isFooterMenuPresent either results in multiple tests or poor test code spoiling the readability.)

4. CI/CD integration. ( Most of the companies were using Jenkins as their CI/CD tool to schedule tests and this is most probably maintained by Devops team. To set up Jenkins job we need a lot of permission. At the worst we need a machine/infra to run and schedule our tests)

How we can solve these commonly occurring problems?

1. With the advent of functional programming, we can pass different behaviours to the test methods. In the demo, I will use BiPredicate Interface implementations to solve this problem with clean design.

2. Annotations in Java is very powerful but hardly used in Test Automation Frameworks. I will use reflections and annotation to solve this problem with a much cleaner design.

3. We can leverage Custom Validator classes and AssertJ to write some effective readable tests.

4. We can leverage Github Actions and the Github runner to set up Selenium Grid Infrastructure and run our tests without any additional infra.

Tech Stack : Java, Functional Interfaces, Selenium, AssertJ, Github Actions

ImageVision is a multi-purpose in-house visual automation tool. It's not meant for replacement of code based automation tools, but it's definitely extending and complementing greatly the traditional code based automation approaches. Even it has proved to be an absolute mandatory in fulfilling the needs of extremely complex visual anomaly detection scenarios and also in many of the complex and tricky UI interactions where the code based automation approaches have been failing to meet the expectations disgracefully.

Listed below various purposes and the features of the tool.

1. Detect various types of anomalies in visual plotting of stream of  sensor  data points in real time, which otherwise would be impossible to detect
2. Perform any type of complex automation interactions as if a real human user would do within the visual plotting regions/widgets or on any part of the target region of the screen/image
3. Capture any web element as an image for further automation actions
4. Compare sets of baseline and runtime images with each other using sophisticated computer vision algorithms
5. Plenty of configurations that offer degrees of flexibility to apply the algorithms as a group or individually and in any order of applying them
6. Potentially offering UI and platform agnostic E2E visual automation capabilities
7. Apply image processing techniques on the basis of configurations including ignoring certain regions of images during grab and compare operations
8.  Comprising three core modules : Image Grab, Image Compare, and Image Interact. Image Interact module is internally      named Actionize
9. Currently, addressing three major anomalous conditions in real time mode: I. data gap in the plotting of data or no plotting for certain amount of time or no plotting continuously or intermittently, II. occurrence of hang issue in the plotting - again continuously or intermittently, III. occurrence of visually flickering effect in the plotting
10. Pretty easy to integrate and use within automation test flows - just one single API call with configurations would carry out all the required tasks and actions
11. Modules can either be run independently or as a sequence of dependent chain based on the tasks or workflows
12. Json format reports each for image grab, compare, interactions, and each anomalous condition
13. The user API set or TDK(Test Development Kit) that invokes the backend engine has been built with TypeScript and JavaScript. A group of backend engines each for unique purpose that carry out the actual tasks and actions has been built with python and computer vision libraries

The automation development life cycle consisting of various activities are eventually aimed at seamless & smooth test scripts executions and lesser time to be spent on failure analysis. In a nutshell, the Test Execution and Failure Analysis are the two critical processes we focus on to get better returns out of test automation. 

There are plenty of modern tools and frameworks that are evolving with more capabilities. However, when it comes to realizing tangible benefits of automation for vastly connected modern Digital Transformation systems and applications, some degrees of tailor-made automation enhancements and customizing features are inevitable especially in the no-cost or low-cost open source tools space.

The pointers below are obviously relatable to any teams that automate Digital Transformation systems that range from dealing with streams of sensor data to Edge and cloud computing to various third party applications and services with open source automation tools. In our case, the E2E web automation tool being Protractor and the test framework being Jasmine along with plethora of npm packages and other tools/libraries.

Common conditions that affect the consistency and reliability of automation runs :

1. Test failures due to unknown error encountered randomly, no consistency in replication of such errors
2. Constantly evolving browser and the browser driver versions
3. Unexpected test time-outs, subtle sync issues between the tool and the application under test
4. In case of failures, regardless of the tools, certain tests can’t be simply re-executed, because the expected default application state is altered by the failed test
5. No control over the occurrence of unexpected run-time failures due to environmental/system state/data reasons
6. Any type of false positives and false negatives
7. Many complex test automation implementations demand regulating systems/tools to be in place that control and regulate the tests at runtime, which are by far the most uncommon thing in the open source space
8. Some variants of a tool is more matured than the other variant at some point in time. For example, it was obvious in the past that Selenium-Java was more matured and stable than WebDriver.js for quite some time
9. More coding and hence more effort and maintenance overhead for keeping up the stability and reliability only on test level
10. Continuous overhead of building and maintaining new CI/CD pipeline stages for reducing the turn-around time for automation reporting where test dependencies are inevitable