QA » openQA Project » openQA Tests » qe-yam

we can have something like this (tested that works):

pom/login-as-root-page.ts

import puppeteer, { Puppeteer, type Locator, type Page } from "puppeteer-core";
import { expect } from "chai";

export class LoginAsRootPage {
    readonly page: Page;
    readonly passwordInput: Locator<Element>;
    readonly logInButton: Locator<Element>;

    constructor(page: puppeteer.Page) {
        this.page = page;
        this.passwordInput = page.locator("input#password");
        this.logInButton = page.locator("button[type='submit']");
    }

    async logIn(password: string) {
        await this.passwordInput.fill(password);
        await this.logInButton.click();
    }
}

test.ts:

import { LoginAsRootPage } from "../pom/login-as-root-page.js";
...
 it("allows logging in", async function () {
        let loginAsRoot = new LoginAsRootPage(page);
        loginAsRoot.logIn(agamaPassword);
    });

Wondering if there is better way to declare those locators than Locator<Element>, I'm not so familiar with the types in TS, let's investigate.

Progress notes: https://progress.opensuse.org/projects/qe-yast/wiki/Agama_and_Puppeteer_Need_To_Know
I've put my findings into the Wiki so that others can avoid doing the same steep learning curve.

Please update to this repo:
https://github.com/jknphy/agama-integration-test-webpack

looks like at the end we could remove the code that use Promises and you could have it as you wanted at the beginning, but it is a hack and I haven't test it yet more than once, you could give it a try and automate this lines so you could develop more comfortable:

• systemctl restart agama.service
• F5 (puppeter can do that with .reload or something similar).

Having that at the begining, the default installation would be just a sequence of lines with readable methods to do stuff.

Iterating through the pages of a default installation.
The open question is if the defaut_installation.ts should be "incremental", meaning containing all pages that were done so far or "differential", meaning to just replace that code snippet with the new page code.
The incremental approach would require either that PRs are merged quickly or that I branch from a branch, e.g.

- product_selection page
  + set root-password page
    + click on install page

Of course, I could do this easily and when product_selection_page PR is merged I rebase to main for the next branch. Sounds like a lot of git fun.

sorry, I don't follow you, the default script contains blocks of code that contemplate two choices, we just need to put there one single POM in one single PR (for example, you can accumulate more than one, it is just an idea) to do the job of the choice that the user would find when running it for first time, so basically replacing each block, once merge nobody would notice your change, no rebase mess.

agreed to do some incremental changes in different PRs.