Correcting Wrong ‘Playwright’s Advantage over Selenium” Part 6: “Features Can Be Configured in One Configuration File”

Convention over Configuration makes even more sense in E2E Test Automation.

Continue to correct the Sixth wrong claim in this YouTube video, “Playwright vs Selenium: What Advantages Make Playwright the Winner in Automation Testing Battle 🏆”.

This article series:

• “Playwright is Modern and Faster than Selenium” 😒

• “Playwright has Parallel Execution Support” 👎🏽

• “Playwright has Native Auto-Waiting Mechanism” 👎🏽

• “Playwright has a native test runner” 👎🏽

• “Playwright has native HTML Reporters” 👎🏽

• “Playwright Features Can be Configured in one Configuration” 👎🏽

• “Playwright supports a range of Testing Types, e.g. API Testing, Component Testing, …” 👎🏽

• “Playwright UI Mode, CodeGen, Debugging support.” 👎🏽

• “Playwright ARIA locator support” 👎🏽

• “Playwright has frequent releases” 👎🏽

• Wrap Up

Claim 6: “Playwright Mammoth Features Can be Configured From One Single Place in Playwright Configurations”

Configuration Files is mainly a Coding Concept

My E2E Test Automation Journey started in 2005, briefly with jWebUnit and then Watir. At that time, the Spring framework was about to take over the infamous EJB. A typical J2EE application has many EJBs, and each EJB has one configuration file, e.g., ejb-jar.xml. The Spring Framework has a more centralized configuration, i.e., fewer configuration files (but a very long one).

Good developers don’t like configuration files.

Veteran programmers might still remember the configurations in EJB and Spring. Yuck! Some wise ones later switched to Ruby on Rails and found out that most take-for-granted configurations are actually not necessary.

“From Java to Ruby — Things Every Manager Should Know” by a renowned Java Guru, Bruce Tate.

Ruby on Rails pioneered ‘Convention over Configuration”, which is regarded as a good software design paradigm.

Configuration Files, in the context of E2E Testing, Make No Sense for End-Users

In a way, end-to-end automated testers act as a proxy for end-users. Therefore, thinking from an end user’s perspective is important when designing automated test scripts. If so, you will realize there is no or little concept of configuration in web test automation, maybe just the web address.

I have been working in Test Automation for nearly 17 years, and there is little need for configuration.

Some Playwright testers would argue, “Playwright is different from manual testing, it has so many features, therefore …”. However, this line of thinking is flawed. End-to-end Test Automation remains entirely independent of any particular test automation framework or language. If someone could show proof (test scripts and long execution history) of little configuration, that would be convincing, right?

Below is the test project structure for E2E test scripts for my WhenWise app. No single configuration file! There were several methods in the test helper with simple customization (see below), that’s all.