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.
Problems with version 1.27
My first steps with Codegen happened with version 1.27. That version was in the middle of a refactoring and created code that did not compile. The bug I reported was quickly fixed. Make sure that you use at least version 1.27.2 (or newer).
Run Codegen
We need to go back to our output folder and run the playwright.ps1 PowerShell script with the codegen option:
|
1 |
powershell .\playwright.ps1 codegen |
If we type that into our console, 2 windows pop up:
The big window is the browser in which we can click through our application, while the smaller window is the Playwright Inspector, where our interactions get recorded as code. The more we click in the browser, the more entries will be in the Inspector window.
Record the first test
If we go to Google and search for Playwright, the recorder should look a bit like this:
If we go to Google for the first time in an incognito browser, a popup comes up that we need to accept. With Playwright this is just another button and we do not need to do anything special to interact with iframes or overlays.
We can click on a result and interact with the web page as we like. Codegen tracks everything and we end up with an understandable code that we can use.
Select the output format
In the example above, Codegen created code for a library project in C#. If you want to change the output format, you can click on the Target dropdown and select the format you want:
If you select NUnit as a target, Codegen rewrites the code as a NUnit test:
Copy to your test suite
Next to the recorder button is a copy icon. If you click on it, the code in the Inspector window is copied to the clipboard:
You can put that code into your test suite and run it with NUnit (or whatever test runner you selected).
Do not forget to clean-up
Codegen is good in finding useful selectors, but sometimes there are better ways to find the elements you are looking for. You can customize the selection so that it meets your requirements.
Add asserts
Tests need asserts, otherwise they just run through web pages, and we will not figure out if something changed that should not have. We need to write those asserts without direct help from Codegen. However, when we want to know the value of a label or a text, we can click on that when we record the test and then use that selector as a starting point for our asserts.
With version 1.28 you get an Explore feature. While recording your test, you can stop the recording, click on the Explore button that appears at the bottom of the Inspector window and select the element you are interested in. You then can copy the generated selector and continue recording your test.
Benefits
The test recorder is easy to use, and you do not need to know much about selectors and testing to record your interactions with a web page. That allows someone who is not a developer to talk to your users and record the actions that are important to them. Your developers can turn those recordings into robust tests without redoing all the work.
If the selectors no longer match, you do not need to rerecord the tests. You can change in your test the changed selectors and it works again.
Downsides
Codegen records UI tests. Do not mistake them for BDD tests (BDD: Behavior-driven development). There will be no record of the intentions of your users, only clicks on a web page.
There is no abstraction over the pages you interact with. If your tests all start on the main page of the application and you change that page significantly, you will need to update a lot of tests.
Next
Codegen can help us to write the interactions for our tests with ease. The generated code will not be perfect, and someone needs to check the selectors. Nevertheless, even with the required rework we can be a lot faster to get our browser automation started. Next week we look at tracing and how we can figure out what went wrong if our tests no longer work.