Playwright Naming Conventions

Background

Playwright automation testing requires locator to find unique element at run time. Usually it is identified by class, id or attribute. While nowadays the development benefits from the tools like MudBlazor, which automatically generates code across the project. As a result, same class, id or attribute could be assigned to multiple elements, which causes violation at run time. Meanwhile the automatically generated class, id or attribute often comes up with meaningless code like '.mud-overlay-scrim' , which is difficult to facilitate Playwright automation testing and development.

Planning

At POC state, it is not required that all elements have naming convention, but the ones testable with Playwright automation. Based on the DevOps features and PBIs, the critical workflows and testing scenarios need to be identified and confirmed by the collaboration of our team and PO/users. Based on decision making, naming convention PBIs will be created and assigned. Once it is done, QA will test to see if that solution workable with Playwright. e.g.

 

Once POC approved and Playwright automation is in place, it is recommend to have naming convention in place at the beginning of components development.

Technical Aspects

While doing the experiment, developer found that, for some tab or popup dialog, if use attribute as naming convention, the added attribute cannot be displayed. Team comes to the decision that both class and attribute will facilitate the naming convention process.

  • In case attribute added, it should follow the pattern

data-playwright=Screen Name+ “-” + Field Type + Short Description

e.g. data-playwright="RegionalManagerReview-lblMeetsMinCrit"

data-playwright="RegionalManagerReview-radioMeetsMinCritYes"

 

 

  • In case class added, it should follow the pattern

class=”PlayWright” + Screen Name + “-” + Control Description

e.g.