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.
|Webdriver Protocol||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.
In October 2021, Neova Solutions provided an internship opportunity. It was a three-month program with 20 students from various institutions and fields. One of them was me.
This is about my journey from an intern to an employee.
During the program we were expecting the following:
- Workplace culture
- To create networking
- to get some hands-on experience
- Working on real-world projects
But it was even more than that.
On the first day, we were greeted warmly by all the employees. Sachin (the Head of Operations) provided us with an outline of the company’s environment and culture. He emphasized that “continuous learning” is the key to success. There were also many leads from various departments who discussed their roles and the spectrum of learning and development at Neova. They also discussed the internship training scope and the schedule for the following three months. We were all greeted with lovely welcome kits. Thanks to HR and the support team for always being there for us.
While this, we were introduced to a buddy system.
Buddy System: We were assigned one experienced employee for each group of three interns, who served as a mentor during our internship period.
We began by installing the Linux operating system, GIT hub, JIRA, and other necessary software. It was a moment of change for us, from reading books and getting marks in exams to reading data and putting it into practice.
After a week, the Java training began. It was about 3 weeks of training with some projects. After a month, React training began, and Java learning was completed.
React training also started from the basic concepts to advance implementation. We also got a chance to work on the front-end design for our respective projects. We had an external trainer for both Java and react. They were experienced and we learned a lot from them.
With so much to learn and so little time, we were all nervous about our projects and performances. Mayur (QA Manager) came to meet us during that time, encouraging us and explaining the scope of QA and what he expected from us.
I recall his remarks “I don’t care how many chores you’re doing; all I care about is that you understand ‘WHY’. Why are you doing this, and what other solutions do you have? Ask yourself and keep your hands dirty with whatever language you are learning”.
And at that point, QA training began with
- STLC (Software testing life cycle)
- Selenium with java
- API testing with postman & selenium java
- Manual testing
We had to do daily meetings with Navdeep and Swapnil in between this training. They kept us motivated and provided us with further information and help.
Soft skills session:
Prasad led the most exciting session of the internship, in which we conversed with one another and shared our stories.
We discussed soft skills and their importance.
- Ability to work under pressure and time management
- Conflict management
A session with Kalpesh (CEO):
Kalpesh was in Pune for a month and during that time, he communicated with us every day and encouraged us to tackle challenging times and problems. He also shared his previous experiences and also about Neova solutions. We got an opportunity to interact with him and learn about his ideology.
Neova’s training and development team often asked for feedback and conducted surveys to see how well the training program was working. When there were any problems, they quickly resolved them and made us feel extremely comfortable.
- Lack of time.
- Few sessions on React were online.
We had a lot of fun celebrating Diwali, Christmas, New Year, and Neovas 14th Anniversary during our internship.
We had proper evaluations done by the leads & managers. Our meetings were set up with the respective team leads of different departments. We were asked about our project execution and the things we learned in training.
That day, we were all tense in the conference room. We’ve all expressed our gratitude and shared our experiences.
The panel members told us “You certainly learned a lot about software here. whether you get selected or not, you will now have an experience that will help you achieve your goals.”
After that, they called us individually to announce the results, and we joined Neova Solutions.
Five Things I learned from this journey:
- Don’t be afraid to ask questions.
- Get involved and take responsibility.
- It is okay to make mistakes.
- Learn new technology.
- Keep an open mind and a positive attitude
Neova Solutions is the best place for continuous learning. Even today after 4 months of being an employee we are learning new things.
Be a part of our innovative team.
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.
Axios is a promise-based HTTP client for the browser as well as Node.js. Using Axios we can perform CRUD operations easily and, thus, it can be used in applications that use libraries such as React or Vue.
- Latest version of Nodejs
- Latest version of npm
- Installation of Axios.
$ node -v V17.8.0
We see that we are using the node version v17.8.0.
$ npm init –y
To initiate a new node.js application.
$ npm i axios
To install Axios
There are different ways by which we can create requests in Axios. Some of them are as given below.
axios(config) axios(URL [, config])
These are other ways of generating requests in Axios.
axios.request(config) axios.get(URL [, config]) axios.delete(URL[, config]) axios.head(URL [, config]) axios.options(URL [, config]) axios.post(URL [, data [, config]]) axios.put(URL [, data [, config]]) axios.patch(URL [, data [, config]])
Step one would be to import libraries like Axios and chai for assertions.
POST method can be used in order to send ‘post’ requests, which can be later used to trigger events like sending the request body to the concerned URL. In this case, the post request can be performed by calling axios.post().
By using this technique, we would be needing two parameters
- URL for the service endpoint
- Object which has the properties needed to be sent.
Since passing data as a parameter to the post method is optional, we can conclude that it is very similar to the get method.
Likewise, we can send a Get request too by using the request function and later calling the get function.
Once the get request is sent, data received in the response and status code 200 is validated using the expect function from chai library.
For update, we use put request while this request we need to send the full body in the request like “name”, “gender”,” email”, ”status”.
Here we are updating user/2364 which we created previously. Once the Put request is sent successfully, assertions are made using the expect function from chai library, and values are compared using the expected property from data with actual values coming in response and status code 200. In this example, we would be changing the gender and status of the person, as we can see below.
Deleting can be done easily by just passing the id we want to delete, Here we check by deleting the user via a delete request. We put assertions to check the status code as the data would be deleted once this request is sent. For a successful request, we expect status code 204.
- Axios can be easily installed therefore providing an easy-to-use API in a compact package for most of your HTTP communication needs.
- Due to the large volume of users, it provides high community support.
- Axios is lightweight and based on Promise API.
- It is isomorphic which means it can run on both, the browser and NodeJS with the same codebase.
- Error handling is quite easy which means that if there is a bad response like 404, the promise will get rejected and thus return an error.
- In the case of small Projects, with just a few simple API calls Axios is not a feasible/ideal solution, instead fetch can be used.
Request is a small library that implements fully and true streaming XHR for browsers that support these methods. It uses a variety of proprietary response Type properties to force a streaming connection, even for binary data. This module comes with built-in protection against ActiveX blocking that is frequently used in firewalls & virus scanners.
- Latest version of Node JS.
- Latest version of npm
Then install Request API in your package to make HTTP requests. Use the code below.
npm install request
You need to install a testing framework to perform API testing using Request API . You can use either Mocha, Jasmine or Jest. Assuming you install Mocha as testing framework by the below code.
npm i mocha
By defining test scripts as mocha in package.json writes your API test cases for GET, PUT, POST, DELETE, PATCH etc…
You need to install a Chai assertions library to get responses to HTTP requests. Use the command below.
npm i chai
Use request to make HTTP responses. A simple syntax for using request is below:
Creating data using the Request in API testing requires a request module offered by npm. To get response we use chai assertions library. You can post an API request using bearer Token and the data needs to create.
In a similar way to POST method GET method also requires library from Request API and chai assertion library. The framework design pattern uses mocha as a testing framework. The code for GET request is below.
For update, data using API request from PUT method follows a similar process as the POST method. The code for the PUT request is below.
By getting status code as 200. That means your data is updated successfully.
To DELETE the data using a delete request and get response code as 204. The code for the DELETE request is below.
- For finding bugs at an early stage of software development, API testing using the Request JS module is an efficient tool for fast and reliable performance.
- Can be used with different testing frameworks like Chai and Mocha.
- We can easily stream the response to the file stream.
- It provides custom HTTP headers.
- The API is currently depreciated and for that reason, no future updates are possible.
- The community support for this API is low in comparison to other testing tools.