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.