I’ve used the Playwright .NET bindings with SpecFlow for a couple of months and it has been a joy to use.
Some of the highlights…
-
Most of the synchronisation issues you have to manage with selenium are gone. Navigating and performing actions on the page just works most of the time and even when it doesn’t, there are very obvious methods like WaitForNavigation or WaitForLoadState that you can use.
-
You can get reasonable browser coverage with Chromium, Firefox and Webkit.
-
Intercepting requests and getting responses is straightforward. For example, After I have uploaded an image I may need to get that image id to check it’s existance on the page somewhere else. I can listen to the api call that uploads that image and generates the id and use the id in the response later in my assertion. Another example is we have auto expiring test data that can be triggered by adding a certain header to the request. With Playwright we can intercept that request, add the header and then resume execution knowing that the test data will be cleaned up automatically.
The only downsides I’ve noticed so far
-
There isn’t much cloud support for running tests remotely. There is no Browserstack support and although it looks like it’s possible with Sauce via saucectl, I’m not sure if that works with all the Playwright language bindings. There is aerokube Moon but that requires you to have knowledge of kubernetes. Fortunately it’s quite straightforward to run tests on any build agent machine.
-
The browser versions look to be tied to the version of Playwright. (Not necessarily a bad thing if you come from a world of needing to manage multiple selenium drivers…)
-
You can’t point to native versions of Safari and Firefox. You have to use Playwright’s built in versions.