QA » openQA Project » openQA Tests » qe-yam

Motivation¶

In order to start to automate Agama web ui, we need a initial script able to control the browser and introduce a default configuration, click on install, wait for installation to finish and reboot.
Out of scope is to create new test modules in openQA to verify that we really install what we wanted but we should verify that manually at least for now.

To develop such script you can use already created script by YaST devlopers that does that except installation itself:
https://github.com/lslezak/agama/tree/master/puppeteer
I did my own version of this script in TypeScript (which offer us with more chances to catch problems and plain JavaScript):
https://github.com/jknphy/agama-puppeteer

Notice that besides the configuration needed to run that script in nodejs with Typescript, I also switched to use locator method instead of low level waitForSelector because in the latest version of puppeteer is not anymore experimental. Puppeteer docs about locator api: https://pptr.dev/guides/page-interactions
There are a few more subtle details that are up to you to discover.

Why Puppeteer and not Playwright?
One thing you might be wondering, why Puppeteer and not Playwright. Playwright offers much more than a library like Puppeteer that many user use for scraping. With Puppeteer we will need an extra effort for learning things that are already connected in a all-in-one solution with Playwright.
Because Playwright works only with specific versions of browsers and doesn't work with the Firefox that ships with Agama Live ISO.
Puppeteer is using a more modern approach cross-browser called Webdriver BiDi. Using that protocol we can connect without problem in all architectures to Agama running in the Live ISO (this was tested manually successfully and confirmed to developers).

Acceptance criteria¶

• AC1: Develop a script that install Tumbleweed using Agama web ui.
• AC2: When creating the script, favor selectors specific from the Pupetteer that point to text in the web page (as most of them are in the example script by developer), no xpath, etc.
• AC2: Test for each architecture that the script is runnable and stable.
• AC3: After the system is install do some simple manual checks cat /etc/os-release, partitioning, networking, etc.

Additional information¶

This ticket can be worked out without #163922 or #163943 be completed as you can run it in your system or in the Live ISO with yupdate. Enablement of this will be done in #163949.
At this point we don't need to use Page Object Model (POM) we just aim to have an script running in all the architectures. We can work on that in #163946.

Documentation
Webdriver BiDi: https://developer.chrome.com/blog/webdriver-bidi-2023
Puppeteer: https://pptr.dev/category/introduction
Mocha: https://mochajs.org/
Chai: https://www.chaijs.com/
Node.js: https://nodejs.org/en/learn/getting-started/introduction-to-nodejs
TypeScript: https://www.typescriptlang.org/docs/

_Troubleshooting with the browser
This is the situation regarding Firefox according to YaST developer:

About the FF version, unfortunately the openSUSE Leap contains Firefox in the ESR (long term support) version 115, the same as in SLES. The next ESR release should be version 128 in Q4/2024, until that we won't see any newer version in Leap I guess.
For using FF 115 from Git you might try commenting out this line in the test: https://github.com/lslezak/agama/blob/master/puppeteer/tests/test.js#L70
That switches to the older CDP protocol instead of the new WebDriver. But I had some problems with that, I have seen some random failures (not find an element which should be on the page). It seems that FF 115 is really old for it.

Or you could try FF from this OBS repo: https://build.opensuse.org/project/show/mozilla
It contains FF 126 for Leap 15.{4,5,6}

If you are using Leap, I would recommend this option to get your FF adding that repo to your system so you can test in local the script without the extra sync required in the Live ISO.

How I am supposed to find those selectors (Puppeteer, Cypress had their own applications to get them)
No fear, although we are using a different protocol to connect to Firefox, to develop we can still use Chrome and CDT:
https://developers.google.com/codelabs/devtools-recorder#0
https://developer.chrome.com/docs/devtools/recorder/overview
Basically you can start recording, interact with the web ui and save your script to Puppeteer, you can change preference for selectors and finally you will have a .js script with a bunch of Promise.race (which basically means that that the script would try to run all of these and then the one that finish first will be used) which of course you most likely will remove as our preference for locator needs to be only one and it is the text on the screen.

How can I know the line failing in TypeScript if the error comes from JavaScript?
Use --enable-source-maps mocha option to have the mapping between with the transpiled code.