I don't think that using Playwright gives us any improvement to build/test performance. It's still ultimately launching a separate browser process and communicating over a websocket. It's mainly stability improvements, for the reasons mentioned.
Playwright is certainly be something that could be useful for UI testing. Probably not as part of RoyaleUnit, but as a separate thing. As I mentioned, it has a pretty extensive programmatic API. You can query the DOM, watch for changes to global variables, evaluate arbitrary JS code, perform user interactions (mouse clicks, keyboard input, etc.). I haven't really dug into everything Playwright is capable of. So far, my only experience with Playwright is specifically running unit tests for Royale and Haxe. -- Josh Tynjala Bowler Hat LLC <https://bowlerhat.dev> On Tue, Aug 2, 2022 at 1:02 PM Harbs <harbs.li...@gmail.com> wrote: > Cool. I was wondering what those references to Playwright were. > > A couple of questions: > > Does this bring any performance improvements? > Does this make UI testing easier? > > > On Aug 2, 2022, at 8:50 PM, Josh Tynjala <joshtynj...@bowlerhat.dev> > wrote: > > > > Hey all, > > > > Recently, I committed some changes to the RoyaleUnit Ant task to make it > > more robust and powerful. This is in response to my recent discovery that > > the RoyaleUnit testing in our royale-asjs build seems to have become less > > reliable over time since I originally set things up. > > > > In particular, I found that Chrome was failing on certain tests because > of > > security restrictions with file:/// URLs (I guess that Chrome was either > > not as strict in the past, or we have added newer tests that are > accessing > > restricted APIs that we weren't using in the past). Additionally, I was > > seeing the occasional intermittent communication failure in Firefox, for > no > > obvious reason. > > > > To remedy this situation, I've integrated Playwright into the RoyaleUnit > > Ant task. > > > > https://playwright.dev > > > > If you're not aware, Playwright is a library that enables automated > testing > > in Chromium, Firefox, and Webkit. Playwright works on macOS, Linux, and > > Windows, and it has a powerful programmatic API (available for a number > of > > languages... we're using the Java version). > > > > By using Playwright, we get some interesting enhancements to our JS > testing: > > > > - Headless > > - No browser windows popping up during long builds > > - Doesn't use your installed browsers > > - Won't litter your default browser with a bunch of tabs that don't > > auto-close > > - No risk of being affected by customized extensions/add-ons > > - It automatically sets up the correct security sandbox > > - No arcane combinations of command line arguments or about:config > > tweaks to get file:/// URLs working as we need > > - The browser debugging console (trace/console.log) messages appear in > > the terminal output of the build > > - Easier to see what went wrong if an exception is thrown during > tests > > > > The "player" attribute of the <royaleunit/> task may now be set to > > "chromium", "firefox", or "webkit" to use a specific browser. RoyaleUnit > > will keep supporting the "html" value for backwards compatibility, and > > it's now an alias for "chromium". You can also use "html" when you want > to > > use a custom browser executable instead of Playwright. > > > > Example of <royaleunit/> in an Ant script that runs JS tests in > > WebKit/Safari: > > > > <royaleunit > > player="webkit" > > swf="${basedir}/target/bin/js-release/index.html"/> > > > >> Aside: Yes, the attribute name for the file/URL is still "swf". That's a > > legacy from FlexUnit. We could add an alias, but it hasn't been a > priority. > > > > I have updated the royale-asjs build to use Playwright, instead of trying > > to detect which browsers are installed locally. > > > > That's not the only change to the RoyaleUnit Ant task that I've made > > recently, though. > > > > First, I should specify it's still possible to specify a custom > > royaleunit.browser property in your env.properties file for the > royale-asjs > > Ant build. If you have that set up already, you don't need to change > > anything. It should keep working the same as before, and your build won't > > use Playwright when royaleunit.browser is defined. However, if you would > > like to switch to Playwright for local builds, you can just comment out > or > > remove the royaleunit.browser property customization from your > > env.properties file (or from the -Droyaleunit.browser command line > > arguments, or any other place you might have set it). > > > > If you'd like to keep using a custom browser, you may be interested to > know > > that the RoyaleUnit Ant task now supports custom arguments when you > specify > > an executable command. Example below: > > > > <royaleunit > > player="html" > > swf="${basedir}/target/bin/js-release/index.html" > > command="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" > > commandArgs="--no-sandbox --user-data-dir=custom_chrome_profile > > --no-first-run"/> > > > >> Aside: The commandArgs above should work well to get tests to pass in > > Chrome with file:/// URLs, even without Playwright. Other browsers may > > require different commandArgs. > > > > I updated the royale-asjs build to optionally support both the > > royaleunit.browser property along with a new royaleunit.browser.args > > property, which you can specify in env.properties, if you prefer not to > > rely on Playwright. Example below (on macOS): > > > > # in env.properties > > royaleunit.browser=/Applications/Google Chrome.app/Contents/MacOS/Google > > Chrome > > royaleunit.browser.args=--no-sandbox > > > --user-data-dir=/Users/joshtynjala/Development/apache/royaleunit_chrome_profile > > --no-first-run > > > > Please let me know if anything seems broken. I've confirmed that > Playwright > > tests are working on CI builds. It's also working on both my local macOS > > and Windows machines. > > > > -- > > Josh Tynjala > > Bowler Hat LLC <https://bowlerhat.dev> > >
