My colleagues and I are investigating the best UI testing automation tooling for us, and I am taking a deep dive into Playwright, exploring its capabilities.
The test generator tool is something that is new to me, at first glance it seemed too good to be true as a quick way to generate something to later be tweaked into ābest practiceā but Iām finding myself struggling with how to use this properly.
One way of using it I feel could be when working with a project that has zero e2e coverage, you could open the project in codegen, then run through lots of different testing scenarios, paste them to be altered later and keep going, to the point where you capture all ābehaviourā underneath well named scenarios. You could then go back to these and tweak them to be proper working tests.
Another way is to use it to quickly populate POMs with individual behaviours which once again, we fill out the POMs and complete our work in codegen, then revisit these POMs and make them best practice.
But what I am discovering is that by using the codegen tool I am starting out by not using best practice. In my experience with Cypress, the only times I would use cy.click at the scenario level is for debugging purposes, I wouldnāt tend to initially write my tests like this. I like to take a POM approach, building out my POM in one go and then creating any functions that I need to, and only then would I start to write out scenarios.
I feel like with my preferred approach, this doesnāt necessarily work so well with the codegen approach. My question is, what is best practice when it comes to UI testing for you-- and especially with Playwright? Do you utilize the codegen test generator (or any other test generator, e.g., Cypress Studio) and if so how do you use it and what is best practice for you when you do so?
Hello
In my humble opinion I would say to use whatever approach feels right for you and /or what is needed for a particular project. āBest practicesā may differ from one org to another and even from a project to another
I use ācodegenā mainly to speed-up the page locator discovery, after that using that info and modifying the scenarios as needed. It can be fantastic for accelerating the initial locator discovery process.
As a conclusion āCodegenā can help identify basic elements quickly and the ābest practicesā can definitely vary depending on the context.
I hope you will find this info helpful
support availability from developers long/short term;
particularities that are not generally covered by available tools or require considerable effort;
product data, product state, stability, locators;
If I have to do something for a serious longer-term project:
Consider the solution design for the Automation framework project.
brainstorm/mindmap/diagram what I want to achieve and how.
document the things, and review with the interested parties that pay or support this product/project: Business, dev leads, CIO, PM, Architect.
considering the limitation of the tool, start by learning if and how the tool can do the pieces that you need; note down the large pieces that need experimentation;
do simple automation scenarios(coding should be a priority - but a mix of code, inspect, generate/record can be added) and restructure code to build the large building blocks.
have the developer/s do a peer review of the code written to improve the state/direction;
have a general product/project demo/technical review every month or two;
In particular to Playwright, I have only found the VSCode Inspector - for locators to be useful half of the time, otherwise itās just software development and good practices from that domain.
One thing I will say is not to let a tool dictate your approach, define your own best practice to fit your needs - it will vary for every team.
Test Generator - there have been many out there in the past, many give you a very flakey test on playback. However, we do use the one that comes with Playwright and find it extremely useful - especially with recent new features that have been added.
We do not take the recorded steps as a standalone test. We use it (as mentioned) to quickly populate our POM files and then set this up for either a pre-written test or to set us up for writing the tests themselves. This does save a lot of time in something that is a āhump of painā.
Good luck and define your own āBest Practiceā that suits the needs of you and your team.
