The first problem we have, is loading our page is really slow. No lib required there, I set up recording a HAR and `routeFromHar` (fallback). Slashed the load time. Next challenge was trickier. When writing tests, I have to keep rerunning the test to get the next line correct.
Ok, live-coding. I'm able to drop a line at the end of my test (or the middle for that matter) and have the headed browser wait until window close. In the console I've exposed a method to pump code back to the test context to be run.
So from the browser console, I ought to be able to type something like `PW_eval('page.playwrightThings')` and it would try to do it. Let's try... success!
A couple days later, we have some event listeners for pressing key chords and moving and clicking the mouse. And we hook up that programmatic part. This is using a lib called 'finder' to get css shortest-path. medv.io/finder/finder.…
you may have noticed the PlaywrightRecorder.startLiveCoding got a second param... it's best to evaluate the code passed in not just in the NodeJS playwright testing context, but in the actual test function, so that locally scoped things are available. This did the trick!
You'll also notice a key combo to re-write and re-run the last executed statement. With this in place you can just gesture to the control you want to interact with, then fill in the details, and it updates in file. Great!
So, how about those rules... I said they're configurable/programmatic. Let's take a look.
The first rule is simplest, it just falls back to a finder lib that returns the css selector as a string. From there the code output takes the selector and puts it in a standard `await page.locator(...).click()` statement.
The next rule is for matching on 'data-testid' attributes. We'll put it first since it's more specific, and fall through to the other. If there's no match, just return undefined and it'll try the next rule down the line.
The third rule is for .nav-link elements, bootstrap stuff I think. In any case, we'd like to grab the .nav-link with the whatever the given text in on the element under the cursor.
Let's revisit that data-testid rule. I've encountered issues where the same control is twice on the same screen, and as a user I can tell the two sets apart, but playwright will want only one selector. Let's detect which nth matching data-testid it is and return that.
and here's a gif of that - I'm modifying the page to have one, then two elements with the same data-testid. At first it displays data-testid=d1, but once it's not unique it returns the object with { selector, nth } values. The output code handles both cases.
Speaking of bugfixes and improvements, the recorderRules code is debuggable right in your browser.
OK, so I created a dumb rule that takes precedence that returns the closest parent 'div' instead of the element under the cursor... not very useful, but it works. oops! I hovered over something that didn't have a parent div. and it crashed the reload process. Bugfixing time.
Normally it's watching and can hot-reload your rules file. The browser even updates in the source and you can add/move/remove breakpoints. It's pretty great.
That's all I have so far, but I'm starting to work on making this system page-object-model aware. I'd like to take the url slug and create a mapping to a page object file. From there I'm figuring out some good conventions that allow for a smooth workflow.
It's tricky being able to execute the code as it's being written. It may be re-running the test is required if you add to a page-object file.
I do intend to make the page-object generating and user editing work hand in hand. That way you're not painted into a corner from either side.
I'm working with my organization to be allowed to open source this. My hope is it'll get traction and Microsoft
@playwrightwebwill take notice! Thanks!
