https://angular.love/modern-e2e-testing-for-angular-apps-with-playwright

[giscus[bot]]

https://angular.love/modern-e2e-testing-for-angular-apps-with-playwright

Angular.love - a place for all Angular enthusiasts created to inspire and educate.

https://angular.love/modern-e2e-testing-for-angular-apps-with-playwright

[Tomek6789]

Hello, this is a great article — kudos!

I have one question. You're creating an Element class with action methods like fillInput and clearInput.
Do you think it's also a good practice to include check methods, such as checkInputValue?

async checkInputValue(expectedValue: string) {
  await expect(this.input).toHaveValue(expectedValue);
}

This way, the test contains only high-level abstractions, allowing 100% focus on user behavior and keeping the tests framework-agnostic.

test.describe('Todos Page', () => {
  test('input should have correct value', async ({ todosPage }) => {
    await todosPage.filterInput.fillInput('Test value');
    await todosPage.filterInput.checkInputValue('Test value');
  });
});

What’s your take on this approach?

[sebastiansmulski]

Thanks for the thoughtful question!

Personally, I prefer to keep assertions like checkInputValue in the actual test files rather than in the page or reusable element model itself. My reasoning is that I treat these reusable element models as building blocks - their primary role is to encapsulate interactions and reduce code duplication, not to define test expectations.

Keeping assertions in the test files helps maintain a clear separation between behavior (in the models) and verification (in the tests). That said, I totally understand the value of your approach but I find that keeping assertions within the test files themselves makes the tests more maintainable and enforces a better separation of concerns.

[sebastiansmulski]

One exception to this might be certain setup actions within an element method - for example, in a clearInput method, it could make sense to check whether the clear button is visible before attempting to click it. In those cases, small internal checks can help make the interaction more robust without without introducing full-blown assertions.

[SayedImran-Jarvis]

In the footer, X social media icon is not visible.

[jasedwards]

I have been undertaking a large project to convert our cypress tests over to playwright. One thing I keep bumping into is opening a form and adding a value to a form control. It seems to really be affected when I open a modal that has an ngForm. I will call .pressSequentially and while the input control is available and visible the typing does not happen. I am assuming it is angular still getting the control ready so I added a check to make sure ng-pending was not on any element. The only thing that ended up working is waitForTimeout calls. I was wondering if you have run into this issue. Oddly enough, when I run this against an ng serve app I don't have a problem but when running against my prod build it is a very large problem.