Playwright is an extremely popular library for browser automation.
It support multiple languages. The officially supported ones are:
- JavaScript/TypeScript
- Python
- Java
- .NET
but there are community efforts to support other languages as well.
In most cases, projects that relies on Playwright are written in a single language.
However, there are cases when you might want to use multiple languages in the same project. This often happens
when your main project is written in a given language but you want to leverage libraries from another ecosystem.
For instance, Python has amazing image processing libraries like OpenCV that can be used to do visual testing,
Java has a wide ecosystem of testing libraries like JUnit and TestNG, and Node.js has a rich ecosystem of libraries
designed to augment Playwright.
In this post, we will take a look at the architecture of Playwright as a library and show how a polyglot approach can be used to
leverage the best of all worlds.
This modal is getting more and more common on the web:
When you see it, you are about to use WebAuthn to authenticate yourself. Under the hood, the operating system will use the fingerprint
sensor to access a private key stored on the device.
Man, what’s gonna happen to UIs is insanely cool
I’m not a believer that chatbots will replace UIs completely. And that’s not because I doubt how crazy good chat interfaces are becoming, it’s because how appealing beautiful UIs are to us humans. GUIs did not kill terminals. But very few use only the command line, because UIs are nice to look at.
But how limited we are by our interfaces!
Most software products today use email verification and multi-factor authentication (MFA) to secure user accounts. This often ends up being a specific pain point for test automation.
Signup and login are critical failure points for any web application. Because they rely on third parties or shared states, authentication flows are hard to test with automated scripts. Some third parties also block browser automation. We've heard many stories of logins and signup flow breaking silently, and nobody noticing until analytics show a drop in user engagement.
At Heal, we believe that end-to-end tests should be as close as possible to the real user experience. In other words, they should replicate what a manual QA tester would do, including verifying emails and entering OTPs.
