Forem: Manoj Kumar

Observability and Selenium

Manoj Kumar — Thu, 18 Jun 2020 19:21:01 +0000

Observability

It is a measure of how well internal states of a system can be inferred from knowledge of its external outputs. It helps bring visibility into systems. – Wikipedia

Tracing is one of the important pillars for measuring observability along with logs and metrics. Its a way of thinking about the system, a way of being able to ask the system questions, that you need the answer to when you didn't know the questions beforehand. On the other hand, alerting is a way of asking questions when you do know the question beforehand.

Distributed Tracing can be quite helpful in answering questions for your distributed system like,

Root cause analysis
Performance optimisation
dependency analysis of services

Selenium-4

It has a number of new exciting features and one such is a cleaner code for Selenium Grid along with support for distributed tracing via OpenTelemetry APIs. This is a pretty exciting and important feature for the admins and DevOps engineers to trace the flow of control through the Grid for each and every command.

Distributed tracing has two parts:

Code instrumentation: Adding instrumentation code in your application to produce traces. The major instrumentation parts are done neatly by the developers of the Selenium project, which leaves us to consume it by using Selenium Grid start-up command along with Jaeger.
Collection of data and providing meaning over it, Jaeger has a UI which allows us to view traces visually well.

Steps to start tracing your tests,

Start Jaeger via docker(as it's easy)
Instrument your Selenium Grid start-up command with Jaeger tracing as in start-grid-distributed.sh and start-grid-standalone.sh for standalone mode.
Now execute your tests, and navigate to http://localhost:16686/ to view the outputs.

Pre-requisites

Assuming you have docker running on your machine,

Install Coursier via homebrew brew install coursier/formulas/coursier
Install Jaeger via docker
Selenium-server.jar refers to the latest alpha version of selenium releases (Tested with Alpha 5)

Start Jaeger via docker server

The simplest way to start the all-in-one is to use the pre-built image published to DockerHub (a single command line).

$ docker run --rm -it --name jaeger \
    -p 16686:16686 \
    -p 14250:14250 \
    jaegertracing/all-in-one:1.17

You can then navigate to http://localhost:16686 to access the Jaeger UI.

Instrument your Selenium Grid command

We're going to add support for Open Telemetry API's(one of the many ways to do distributed tracing) using Coursier to generate a full classpath when started this way the selenium server will inform you that it has found a tracer on stdout.

Refer start-grid-distributed.sh if you want to start Grid in distributed mode.

curl http://localhost:4444/status

to check if your grid deployment is ready

Execute your tests

Point your tests as in DistributedTracingExamples Class and navigate to http://localhost:16686/ to view the outputs.

Under services lookup for Selenium-router and notices actions for each call made by your tests. An example below

References:

A special thanks to ever-helpful Simon Stewart

Thanks, folks!
Follow me on Twitter

Getting Started with GraphQL

Manoj Kumar — Thu, 11 Jun 2020 15:33:57 +0000

What is GraphQL?

GraphQL is an API specification standard and an Open-Source data query and manipulation language. It has a server-side runtime fulfilling those queries along with the data. In other words, GraphQL follows WYAIWYG pattern What You Ask Is What You Get. GraphQL allows declarative data fetching where a client can specify what data it needs from an API.

Facebook invented GraphQL, and now it is maintained by a large community of companies and individuals all over the world. GraphQL is a specification and, users shall create their implementation on different platforms conforming to the specification. Therefore, Netflix Open-Sourced their implementation called Falcor. An easy example for folks coming from Test Automation world, it is like WebDriver being a W3C Specification, Selenium and WebDriverIO are its browser automation implementation.

GraphQL has two parts:

A Server component, a GraphQL server to accept the incoming requests and send back data precisely.
A Client component, to send a POST request (with payload) to the GraphQL server.

GraphQL uses a type system to define the capabilities of an API. All the types declared in an API are written in a schema using the GraphQL Schema. Namely, Schema Definition Language (SDL). It serves as a contract between the client and the server to define how a client can access the data. Defining the Schema allows the back-end and front-end teams to concentrate on their piece of work without much communication.

More content here: https://blog.testproject.io/2020/06/11/introduction-and-getting-started-with-graphql/

What's new in Selenium 4?

Manoj Kumar — Thu, 11 Jun 2020 15:28:13 +0000

A cross-post of Selenium 4 article.

A lot of developments have happened since Selenium 4 was announced during the State of the Union Keynote by Simon Stewart and Manoj Kumar. There has been a significant amount of work done and we’ve released at least six alpha versions of Selenium 4 for users to try out and report back with any potential bugs so that we can make it right.

Selenium WebDriver

One of the main reasons to release WebDriver as a major version (Selenium 4) is because of the complete W3C protocol adoption. The W3C protocol dialect has been available since the 3.8 version of Selenium WebDriver along with the JSON wire protocol. This change in protocol isn’t going to impact the users in any way, as all major browser drivers (such as geckodriver and chromedriver), and many third party projects, have already fully adopted the W3C protocol.

However, there are some notable new APIs, as well as the removal of deprecated APIs in the WebDriver API, such as:

Elements:
- The FindsBy* interfaces (e.g. FindsByID, FindsByCss …) have been deleted. The recommended alternative is to use a By instance passed to findElements instead.
- “Relative locators”: a friendly way of locating elements using terms that users use, like “near”, “left of”, “right of”, “above” and “below”. This was inspired by an automation tool called Sahi by Narayan Raman, and the approach has also been adopted by tools like Taiko by ThoughtWorks.
- A richer set of exceptions, providing better information about why a test might have failed. These include exceptions like ElementClickInterceptedError, NoSuchCookieError & more.
Chrome Debugging Protocol (CDP): Although Selenium works on every browser, for those browsers that support it, Selenium 4 offers CDP integration, which allows us to take advantage of the enhanced visibility into the browser that a debugging protocol gives. Because the CDP is, as the name suggests, designed for debuggers, it’s not the most user friendly of APIs. Fortunately, the Selenium team is working to provide comfortable cross-language APIs to cover common requirements, such as network stubbing, capturing logs, mocking geolocation, and more.
Browser Specifics: A new ChromiumDriver extends packages for both Chrome and Edge browsers. A new method to allow install and uninstall add-ons for Firefox browser at runtime.
Window Handling: Users can go in full-screen mode during script executions. Better control of whether new windows open as tabs, or in their own window.
Screenshots: An option to grab a screenshot at UI element level. Unlike the usual view-port level screenshot. Full Page Screenshot support for Firefox browser.

What’s next in WebDriver beyond Selenium 4?

It would be nice to have users extend the locator strategy like FindByImage or FindbyAI (like in Appium) – right now we have a hardcoded list of element location strategies. Providing a lightweight way of extending this set, particularly when using Selenium Grid, is on the roadmap.

There are a lot of other features added to Selenium IDE and Selenium Grid. Please refer https://applitools.com/blog/selenium-4/ for more content