Goal

Add Playwright-based UI smoke tests to the CI build.yml workflow that test the OpenIDM UI against a real running OpenIDM server on localhost:8080. The existing QUnit tests only run against mocks — these new tests will verify the UI works end-to-end with a real backend.

What to add

1. Create e2e/playwright.config.mjs

import { defineConfig } from "@playwright/test";

export default defineConfig({
    testDir: ".",
    testMatch: "**/*.spec.mjs",
    timeout: 60000,
    retries: 1,
    use: {
        headless: true,
        baseURL: process.env.OPENIDM_URL || "http://localhost:8080",
        ignoreHTTPSErrors: true,
        screenshot: "only-on-failure",
        trace: "retain-on-failure",
    },
    reporter: [["list"], ["html", { open: "never", outputFolder: "playwright-report" }]],
});

2. Create e2e/ui-smoke-test.spec.mjs

The test file should cover these scenarios, all running against a real OpenIDM at http://localhost:8080:

1. Admin UI login page loads — GET /admin/ returns 200, the #login and #password input fields appear (these are the standard ForgeRock commons-ui LoginView selectors).

2. Admin UI login with openidm-admin succeeds — fill #login with openidm-admin, fill #password with openidm-admin, click the submit button ([type=submit] or .btn-primary), and verify the login form disappears and page content loads (e.g. #content, .navbar, or #wrapper becomes visible).

3. Enduser UI login page loads — GET / returns 200, #login and #password fields appear.

4. REST API ping is accessible — GET /openidm/info/ping with headers X-OpenIDM-Username: openidm-admin and X-OpenIDM-Password: openidm-admin returns 200 with state: "ACTIVE_READY".

5. REST API config endpoint is accessible — GET /openidm/config/ui/configuration with the same auth headers returns 200 and has a configuration property in the response.

6. Admin UI Dashboard loads after login — after logging in, navigate to #dashboard/ and verify no .alert-danger error elements are visible.

7. No JavaScript console errors on Admin UI load — listen for pageerror events, load /admin/, wait for it to settle, and assert no critical JS errors occurred (filter out favicon/404 noise).

Use process.env.OPENIDM_URL || "http://localhost:8080" as the base URL throughout. Use timeouts of 30s for waitForSelector since OpenIDM UI loads can be slow.

3. Modify .github/workflows/build.yml

Add a new step after the existing "Test on Unix" step (which already starts OpenIDM and waits for "OpenIDM ready") and before the "Test on Windows" step. The new step should:

• Only run on Linux: if: runner.os == 'Linux'
• Install Playwright and Chromium, then run the tests:

      - name: UI Smoke Tests (Playwright)
        if: runner.os == 'Linux'
        run: |
          cd e2e
          npm init -y
          npm install @playwright/test
          npx playwright install chromium --with-deps
          npx playwright test --reporter=list
        env:
          OPENIDM_URL: http://localhost:8080

Important: Do NOT modify the existing "Test on Unix" or "Test on Windows" steps. Do NOT remove or change the existing QUnit test steps from PR #144 if they are present on the branch. Just add the new Playwright step as described.

4. Do NOT add

• Do not add e2e/node_modules or e2e/package-lock.json — they should be generated at CI time
• Do not modify any existing test files or Gruntfiles
• Do not add Playwright to the root package.json or any existing package.json

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: я остановил сервер на порту localhost:8080/openidm и тест прошел, это говорит о том, что тесты остались на моках

Assistant:

Вы правы — это важное наблюдение. Если тесты проходят даже когда сервер на localhost:8080/openidm остановлен, это подтверждает, что QUnit тесты в openidm-ui полностью работают на моках (mocks/stubs) и не делают реальных HTTP-запросов к бэкенду.

Это на самом деле хорошо для CI — означает, что:

1. Тесты самодостаточны — им не нужен запущенный OpenIDM сервер
2. Они тестируют фронтенд-логику изолированно — через замоканные ответы API
3. Их можно запускать в CI без сложной инфраструктуры — не нужно поднимать базу данных, сервер приложений и т.д.

Это типичный паттерн для UI unit-тестов — они используют sinon.js или подобные библиотеки для перехвата XHR/fetch запросов и возврата предопределённых ответов.

Хотите, чтобы я обновил PR #144, учитывая это? Раз серверная часть не нужна, CI-конфигурация может быть проще — достаточно только headless-браузера и Node.js окружения для запуска QUnit тестов.

User: нет, я хочу в build.yml протестировать UI на реальном localhost:8080/openidm

Assistant:

Понял — вы хотите в CI workflow (build.yml) запускать UI тесты против **реального работающего ...