How do all the popular browser automation tools work under the hood? Can they incorporate missing features in the near future based on their architecture and how their architecture compares to each other test runners?
The underlying architecture of all the browser automation tools are quite different. To communicate and control the browser and the application under the test, the majority of tools can be categorized into three categories:
- WebDriver protocol
- Chrome DevTools Protocol (CDP)
We can categorize the available browser automation tools into two groups, The ones that operate on the Webdriver and the ones that are based on the Chrome DevTools Protocol (CDP).
Selenium was an independent tool until it merged with a similar tool called WebDriver and hence became Selenium Webdriver. Every supported browser version must provide a driver that Webdriver uses for communication. This makes these frameworks cross-browser compatible. This protocol provides you with better support for running the same tests on different browsers and browser versions.
Unfortunately, Webdriver based tests have the reputation to be flaky which means that if they run under the same circumstances multiple times, they can either fail or succeed. That shows a bad reputation for a testing framework. You spend a good amount of time building something that should guarantee the stability of the application and then you cannot even trust that.
Some of the popular tools implementing this protocol are: Selenium Webdriver, WebdriverIO, Nightwatch
Chrome DevTools Protocol (CDP)
The Chrome DevTools Protocol (CDP) uses WebSocket connection to communicate from the test runner to the browser. DevTools are present in all modern browsers. As the name suggests it is a tool for developers which helps to analyze and debug.
CDP tool is available for Chromium-based browsers (Chrome, Edge, Opera, Brave). You can access this developer tool by using the keyboard shortcut CTRL + SHIFT + I or F12
Two quite popular tools are Puppeteer and Playwright. They do not depend on the Webdriver but instead talk directly to the browser via the Chrome DevTools Protocol (CDP). This provides them with much better control which leads to more stable tests.
Some of the popular tools implementing this protocol are: Playwright, Puppeteer.
The application and the tests share the same process & domain.
Hence, the test can directly access the
- Application’s objects
- Browser APIs.
By sharing the event loop, the test and the app take turns: When the app is running, the test code is waiting, when the test code is running, the app is paused. This guarantees that the application does not change between the test steps.
Some of the popular tools implementing this protocol are: Cypress, TestCafe.
Flakiness vs. Cross-Browser
From a very high-level point of view, the closer we get to the browser the more stable the tests become but very less support for cross-browser. On the other hand, the more abstraction we have between our tests and the browser, the flakier tests tend to become but will get more support for cross-browser.
|Chrome DevTools Protocol
|Developed by: W3C
|Developed by: Chrome Developer Tools
|Needs drivers (proxy servers)
|No need for drivers
|Relatively slow and More Flaky
|Fast and Less Flaky
|Supports most of the browsers (More cross-browser support)
|Supports only modern browsers (Less cross-browser support)
|No access to network-related info (does not support API testing)
|Has access to the network (Supports API testing)
|Tools Implemented: Selenium WebDriver 3, WebdriverIO, Nightwatch
|Tools Implemented: Playwright, Puppeteer, Selenium Webdriver 4, Cypress v7
- Currently, Selenium Webdriver 4 and WebdriverIO are trying to go beyond JSON HTTP protocol to using a bidirectional WebSocket protocol similar to CDP.
- The Playwright team is patching Firefox and WebKit (Safari) to allow CDP to work with all major browsers.
- Cypress also has CDP support built-in already from v7 onwards.
In the future, all browsers might support CDP, or the upcoming protocol known as WebDriver BiDi which will bring stability into the WebDriver world. Things are still evolving.
Considering it all together, this is the current state of the browser automation protocols used for various popular tools available in the market as of now:
Happy Automation Testing!
REST-assured enables you to test REST APIs using java libraries. It is very efficient and easy to use. Integration with maven is also easy. REST-assured has methods to fetch data from every request and response part.
It can be used to test XML & JSON-based web services, however, the structure is complex.
- JDK should be installed in the system.
- IDE for running and executing java code (either eclipse or other).
Firstly, you must create a new maven project in your eclipse IDE. Then we need to add a dependency for rest assured and testNG to execute code for API testing.
The below dependency is for REST-assured added to your pom.xml file in your maven project.
Apart from that, you need to add TestNG framework to your maven project. For that, you need to add a dependency for TestNG.
Then, you need to go to src/test/java in your maven project and you can either create a new java class or write code in the default class.
The syntax of REST-assured is easy and similar to the BDD structure. It uses given/when/then, therefore it is easy to understand and readable.
To create data using REST-assured we use post() method. Firstly, we should have data in the form of JSON Object and authorization tokens as needed. Using TestNG as testing framework we can post any request as defined in the code below:
By getting status code as 201. That means your data is created successfully.
To read the data using get() request in REST-assured with TestNG framework use the code below.
To update data using REST-assured we use put() method. Firstly, we should have data in JSON Object and authorization tokens as needed. Using TestNG as a testing framework we can update any data as defined in the code below:
By getting the status code as 200. That means your data is updated successfully.
To DELETE the data using REST-assured and get response code as 204. The code for DELETE request is below.
- It is easy to use since it uses given/when/then test notations which are readable easily.
- Easy to integrate with frameworks like TestNG and JUnit.
- Code reusability is excellent as it is a Java client.
- CI/CD integration is easy as we can easily integrate with tools like Maven and Jenkins.
- REST-assured can be used with customized and open-source reporting tools.
- It provides DSL so the test is Behaviour driven.
- It provides an easy interface, which is why it is a better tool rather than other complex tools.
- Does not support SOAP APIs explicitly.
- There is no inbuilt reporting in REST-assured.
- Since it uses Java as a programming language thus requires good knowledge of Java.
When trying to decipher RESTful APIs created by others or test ones you have built yourself, Postman is a fantastic tool. It provides a simple user interface for making HTML requests, reducing the need to write a lot of code only to evaluate an API’s operation.
Testing is more efficient with Postman. Simply paste the path into the address bar, select the GET response method from the selection box to the left, enter your API key in the “Headers” area, specify “pretty” JSON as the return format, and hit submit. The response data will be in easy-to-read JSON format, with a status code of 200 indicating that the GET request was successful. That is all there is to it!
You should be familiar with APIs, automation and manual testing.
The Process of using Postman is quite simple and easy. Using Postman is a basic and straightforward process. The setup may be downloaded for all systems, including Windows, MacOS, and Linux, from its official website. Simply download and install the application on your machine, then begin testing the APIs.
It is simple to install in Linux and Ubuntu by typing the following command in the Terminal:
$sudo snap install postman
As Postman is totally a GUI based Testing Tool, it does not have any specific Syntax to write/Test the APIs
CRUD stands for Create, Read, Update and Delete. There are four basic database operations that correspond to the most used HTTP verbs in Rest Services.
It is used to create a new resource but can also modify the underlying state of a system.
It is used to retrieve a representation of resources.
It is used to Update an existing resource.
It Deletes the existing resource.
Collection [API Automation]
To keep your workspace organized, engage with coworkers, develop API documentation and API tests, and automate request runs, you may arrange your Postman requests and examples into collections. To see a list of collections in a workspace, go to Collections in Postman’s left sidebar.
- It is quite easy to import or export a collection, which saves time when transferring requests.
- When you set a variable for a collection, it will also be applied to the folders that are created under that collection.
- It is simple to transmit data across collection requests.
- Using collection variables, data exchange between APIs is a breeze.
- There will be no need to build common test cases for distinct requests because tests written at the collection level will be relevant to all requests inside the collection.
- Using the collection runner, all requests can be executed at the same time.
- A CSV or excel file can be used to do data-driven testing.
- With the help of collection and Newman, continuous integration is simple.
To run an automated test from a Collection, we can simply click on three dots on Collection Folder and Select the third option Run Collection, and it can perform all the test cases of CRUD Operations like create, put/patch, delete and get etc. Automatically.
And in the next window, we can rearrange the order of the operation, and select the no. Of the iterations and the delay between each operation and can run all the operations inside the Collection.
Once all the test cases run fine, it will give us the Status Code (Yellow), the time to execute the test case (Green), and the size of the tests for each operation (Pink).
- It is User-friendly. Testers may quickly develop test suites by filling in templates using a simple interface. Postman also includes code samples for script construction, including examples of response time, response code, and other validations.
- Accessibility. Postman users may easily access their files by logging into their account on a device that has the Postman app, or the Postman browser extension installed.
- Various functionalities are available. All HTTP methods are supported by Postman, as well as saving progress, converting APIs to code, altering the API development environment, and many other features.
- Capabilities for tracking requests. Postman supports many status codes for HTTP responses, allowing users to check the response. To name a few, there are Successful requests, Empty responses, Bad requests, and Unauthorized access.
- There is a limited amount of testing space. Postman is great for testing RESTful APIs, but it is not so great for SOAP APIs and other APIs.
- The reusability of scripts is limited. Users of Postman are unable to reuse or add more requests to their pre-written scripts. This means that testers will have to write fresh test scripts for each project. Integration that is restricted.
- While APIs make the Agile process possible, the product itself has limited integration options. Connecting Postman to current systems and interacting across the team becomes a challenge.