Web Automation using Selenium and Cucumber with Java
Web Automation using Selenium and PyTest with Python
API Automation Testing using Robot Framework with Python
API Automation Testing using Requests Library of Python
API Automation Testing Using Cypress with JavaScript
Browser Automation Tools Protocols – Webdriver vs CDP
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)
- Native (JavaScript loaded in the same browser application)
WebDriver Protocol
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.
Native (JavaScript loaded in the same browser application)
The application and the tests share the same process & domain.
Hence, the test can directly access the
- DOM
- 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 |
Future Trends:
- 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!
Configuring Eclipse for Protractor
If you are using Protractor for automating AngularJS application testing, you have a choice to use a paid IDE like Webstorm or can also choose Atom or Sublime. Eclipse one of the most popular open source IDE’s has a plugin Tern that is a stand alone code-analysis engine for JavaScript.
But before using eclipse Tern IDE, Eclipse needs to be configured.
Steps for eclipse configuration:
- Install “Tern Eclipse IDE” from the eclipse marketplace, accept the license.
- Create a new Java Project.
- Remove src and JRE, as those are not required.
- Now right-click on Project and configure it by clicking convert to Tern project.
- Once done, do select Protractor from the library set on the Modules selection window.
- Click on save and configure.
Once done, you can create a Protractor project, helping you with in-built library methods. But the configuration file cannot be run directly from Eclipse run. In order to configure Eclipse run, follow the steps:
- Create conf and spec file inside your project.
- Create runner.bat file, containing run command e.g. Protractor conf.js.
- Now click on run ->External Tool Configuration.
- Select New Configuration within program.
- Select respective project folder in working directory section and runner.bat file in main section.
- Once done, click on save and apply.
- Now user can run project just by clicking on the “Run Last Tool” button.
Neova has expertise in automation testing of AngularJS applications using Protractor.
Why continuous security testing should be on your to-do list?
Continuous security testing is an absolute approach towards an effective security strategy. In this era of shifting attacks, we should be more vigilant.
WHY IS SECURITY TESTING A CONTINUOUS PROCESS?
Your application is vulnerable to an attack where the exploit is developed after you deployed the last security patch. The malicious attackers are getting smarter, they analyze the new patch and change their strategy according to the latest security patch.
The application requires a significant amount of collaboration of multiple module to function rightly. There is an application code, business logic, back-end network, client side, database, APIs, machines, its operating system and the users. Every component plays a vital role in the security of an application.
Any web application or mobile application should upgrade its components as and when there is an update and test them against new vulnerabilities.
COMPONENTS OF AN APPLICATION:
If there is any vulnerability in one of the components, the application is vulnerable to attacks. To keep the application secure, one needs to keep updating their approach towards security.
1. APPLICATION CODE AND BUSINESS LOGIC:
To keep them vulnerability free you should perform security testing. Review the code and logic when there are new changes.
2. THE BACK-END NETWORK AND MACHINE:
You should frequently perform a security audit of your network and machine, where the application is hosted.
3. THE CLIENT-SIDE, API, AND DATABASE:
This place is exploited by hackers. They mainly use the vulnerability of this section to bring the application down or for stealing your data. To keep the application secure one should perform vulnerability assessment and penetration testing against the latest threat discovered.
4. THE HUMAN INVOLVEMENT IN THE PROCESS
Human is the most vulnerable part of the security chain. According to a study, more than 90% of data breaches are due to human negligence. Any application is built by the people, for the people. So vulnerability can be introduced by the product development team and the user. Security testing alertness programs will create awareness about how they are helping malicious attackers unknowingly and to avoid such unwanted situations. There should be clear and effective communication with users so that they can avoid security threats related to the product.
WINDING UP WITH A SMALL NOTE.
Start implementing security testing as a tradition. If you have any questions regarding end-to-end application security testing contact us.