A side effect we noticed after the migration to .Net 6 was that the test task in Azure DevOps took a lot longer than before. The test execution itself did not change much, but the dotnet test task had much more overhead than vstest. As an example, the test task took 4m 48s, while the test execution only took 1m 34s – giving us an overhead of 3m 14s or roughly 75% of the total time:
Last week I was in Oslo to attend the NDC conference. I cannot really believe that this was already the 10th NDC Oslo I attended. With 2’600 attendees it was the biggest NDC event ever, but at least for me not the best.
If you ever run into a problem with an iPhone and need to create a video of your screen, you can do that directly with the methods provided by iOS (back to iOS 13).
After my series of 13 posts about Playwright spanning C# and Python, it is time to answer the two question I got asked a lot in the past few weeks:
Is Playwright ready for production?
Yes
Should we switch to Playwright?
It depends.
The second one is a boring answer, but if you want to have my honest opinion, then that is it. Let’s recapitulate what we covered in this blog series and add the context to the favorite answer of consultants.
After last week's success with BrowserStack, I tried to run Playwright on Selenium Grid. The user experience for this use case is at the opposite end of the scale. The documentation is not much help and Selenium Grid has its own incompatibilities. Let's look at how we can still make it work.
At work we use Selenium and BrowserStack for end-to-end tests in C#. How much work is it to connect Playwright to BrowserStack?
When you work with Playwright, there are a few small things that you want to change. Often there is a flag for codegen or a settings value that will do the trick. I collected the customisations for the parts I find most useful. Feel free to add a comment for other tricks you think I should know about.
The customisations go in 3 basic places: The command line for changes to codegen, the BrowserTypeLaunchOptions() when we launch the browser or the context that we get from the newly created browser. If you get stuck, you best use the codegen option and then look at the generated code to copy that into your application. That works across languages and frameworks.
If you need to find out what went wrong during an end-to-end test, a recorded video of the browser with all its interactions can be a time saver. What is true for Selenium Grid is also a good idea for Playwright. Let's look at how we can create these videos with in NUnit and a library project.
Playwright has a great trace viewer that allows us to see exactly what is happening in our tests. This is especially helpful when something goes wrong. Let's take a look at how we activate tracing and access the information it collects.
Test recording has a bad reputation: The generated code is brittle, ugly and contains so many details that developers do not bother to understand it – instead, they start over from scratch. Microsoft did its part in creating that bad reputation. But Microsoft learned its lessons and did a big step forward with Codegen, the test recorder for Playwright.