From fbfcb1defcaf616870db2639d38cd33e32f1d90a Mon Sep 17 00:00:00 2001
From: Ekhorn <koen@kschellingerhout.nl>
Date: Sun, 25 May 2025 19:02:25 +0200
Subject: [PATCH 01/15] Add frontend testing guide

---
 docs/developer-guide/frontend-testing.md | 120 +++++++++++++++++++++++
 1 file changed, 120 insertions(+)
 create mode 100644 docs/developer-guide/frontend-testing.md

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
new file mode 100644
index 0000000..2f1f678
--- /dev/null
+++ b/docs/developer-guide/frontend-testing.md
@@ -0,0 +1,120 @@
+# Frontend Testing Guide
+
+<!-- This document describes the frontend test architecture used in this codebase, including the design decisions behind E2E and component testing separation, the fixture system, and setup/teardown strategies. It is intended as a **transfer document** for onboarding or handover purposes. -->
+
+OpenRemote uses [Playwright](https://playwright.dev/) for frontend-testing. Playwright was originally created to enable end-to-end testing i.e. testing through a browser just like how the user would this usually requires the backend to run. Though Playwright added an experimental feature for component testing. Allowing you to use the same Playwright APIs, but on individual components.
+
+## Test Organization
+
+The frontend tests are organized under `component` and `e2e` (end-to-end) tests.
+
+### General setup
+
+All frontend testing code is situated under the `ui` directory. We use different Playwright configurations for `component` and `e2e` testing.
+
+- `ui/playwright-ct-config.ts`: Component testing configuration
+- `ui/playwright-config.ts`: End-to-end testing configuration
+
+We do this because we modify the base configuration that comes with the `defineConfig` function for component testing to work, however this configuration is incompatible with e2e testing thus we use 2 configurations.
+
+#### Shared test package
+
+Both `component` and `e2e` depend on the `@openremote/test` package which includes shared fixtures and our Playwright component testing plugin. Playwrights' component testing comes with Vite, but this is incompatible with the `commonjs` imports used in some components.
+
+Playwright uses Vite under the hood for component testing to mount a component to a HTML page. However OpenRemote uses Webpack, and thus we created our own Playwright plugin that mimics this but bundles the component and mounts them through webpack.
+
+### Component test setup
+
+The component tests are used to test individual `lit` (web) based components.
+
+```ts
+// playwright.config.ts
+export default defineConfig({
+  projects: [
+    {
+      name: 'e2e',
+      testMatch: /.*\.e2e\.spec\.ts/,
+      workers: 1, // One worker to allow shared Manager setup
+    },
+    {
+      name: 'component',
+      testMatch: /.*\.component\.spec\.ts/,
+      // Parallel execution allowed
+    },
+  ],
+});
+```
+
+The setup is based on the
+
+- Dev Server: `@openremote/test`
+- `playwright`
+
+##### Configuration
+
+The component tests run in parallel.
+
+- **Target:** UI packages (each component is a standalone NPM package).
+- **Runner App:** A dedicated app called `playwright` (used for component mounting).
+- **Testing Strategy:** Based on Playwright’s experimental component testing API, but adapted to Webpack using a custom plugin.
+
+### End-to-End test setup
+
+The end-to-end tests are used to test app functionality from the frontend.
+
+##### Configuration
+
+The end-to-end tests run on sequentially using 1 worker to avoid tests interfering with each other.
+
+- **Target:** The `manager` app.
+- **Worker Scope:** Single worker (to avoid tests interfering with one-another).
+- **Fixtures:** Shared Manager fixture (`scope: 'worker'`) is used for initializing global resources like realm creation, auth sessions, etc.
+
+## Writing tests
+
+**Component test**
+
+**End-to-end test**
+
+Playwright uses [`locators`](https://playwright.dev/docs/locators) to find elements in the DOM. It's crucial to know the different types of locators to be able to write tests that are robust and to avoid flaky behaviour.
+
+### Tips
+
+#### Playwright features
+
+The most useful feature Playwright provides when it comes to writing frontend tests is [UI mode](https://playwright.dev/docs/test-ui-mode). Once the Playwright UI is launched you can select which projects you want to see and run.
+
+The UI includes a locator tab, which allows you to click an element in the test preview to get a selector.
+
+```sh
+npm test -- --ui
+npm run e2e -- --ui
+```
+
+In case you want to see how Playwright runs in a headed browser you can add the `--headed`.
+
+```sh
+npm run e2e -- --headed
+```
+
+See https://playwright.dev/docs/test-cli#reference for more CLI arguments.
+
+#### Flaky tests
+
+Use `waitFor` and
+
+### Best practices
+
+Please read the [Playwright Best practices](https://playwright.dev/docs/best-practices).
+
+<!-- TODO: include what to do and what not to do -->
+
+**TL;DR**
+- Avoid `xpath` and `css` selectors.
+- Isolate tests, so you can rerun them without relying on external factors such as other tests.
+- Use [web first assertions](https://playwright.dev/docs/test-assertions) e.g. `toBeVisible`, `toBeHidden`, `toBeChecked` etc.
+- Reuse locators and actions through test fixtures
+- Use the test report, traces and debugger
+<!-- - Enable multiple browsers (see playwright UI checkboxes) -->
+
+### Performance

From ebf8592de86ae0ad23fd64bf6586e9e133a6ee0b Mon Sep 17 00:00:00 2001
From: Ekhorn <koen@kschellingerhout.nl>
Date: Tue, 3 Jun 2025 17:18:19 +0200
Subject: [PATCH 02/15] Update frontend testing guide

---
 docs/developer-guide/frontend-testing.md | 138 ++++++++++++++---------
 1 file changed, 82 insertions(+), 56 deletions(-)

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
index 2f1f678..7666e25 100644
--- a/docs/developer-guide/frontend-testing.md
+++ b/docs/developer-guide/frontend-testing.md
@@ -1,8 +1,6 @@
-# Frontend Testing Guide
+# Frontend Testing
 
-<!-- This document describes the frontend test architecture used in this codebase, including the design decisions behind E2E and component testing separation, the fixture system, and setup/teardown strategies. It is intended as a **transfer document** for onboarding or handover purposes. -->
-
-OpenRemote uses [Playwright](https://playwright.dev/) for frontend-testing. Playwright was originally created to enable end-to-end testing i.e. testing through a browser just like how the user would this usually requires the backend to run. Though Playwright added an experimental feature for component testing. Allowing you to use the same Playwright APIs, but on individual components.
+OpenRemote uses [Playwright](https://playwright.dev/) for frontend-testing. Playwright was originally created for end-to-end testing i.e. testing through a browser just like how the user would interact with an application. This usually requires the backend to run, making them considerably slower than unit- or component tests. Playwright has added an experimental feature for component testing. Allowing you to use the same Playwright APIs on individual components for better test isolation and easier parallelization.
 
 ## Test Organization
 
@@ -15,83 +13,119 @@ All frontend testing code is situated under the `ui` directory. We use different
 - `ui/playwright-ct-config.ts`: Component testing configuration
 - `ui/playwright-config.ts`: End-to-end testing configuration
 
-We do this because we modify the base configuration that comes with the `defineConfig` function for component testing to work, however this configuration is incompatible with e2e testing thus we use 2 configurations.
+We do this because we modify the base configuration that comes with the `defineConfig` function for component testing to work, however this configuration is incompatible with E2E testing thus we use 2 configurations.
 
 #### Shared test package
 
-Both `component` and `e2e` depend on the `@openremote/test` package which includes shared fixtures and our Playwright component testing plugin. Playwrights' component testing comes with Vite, but this is incompatible with the `commonjs` imports used in some components.
+Both the `component` and `e2e` tests depend on the `@openremote/test` package which includes shared fixtures and our Playwright component testing plugin. Playwrights' component testing plugin comes with Vite, but this is incompatible with the `commonjs` imports used in some components. Playwright uses Vite to bundle and mount a component to an empty HTML document for testing. Our Playwright plugin mimics the Vite based plugin using Webpack so we can mount our components to the document without import issues.
 
-Playwright uses Vite under the hood for component testing to mount a component to a HTML page. However OpenRemote uses Webpack, and thus we created our own Playwright plugin that mimics this but bundles the component and mounts them through webpack.
+The `shared` fixture in the test package is meant for general test utilities like intercepting requests. The `components` fixture is specifically meant for utitilies related to components to share common actions between component- and E2E tests.
 
 ### Component test setup
 
-The component tests are used to test individual `lit` (web) based components.
-
-```ts
-// playwright.config.ts
-export default defineConfig({
-  projects: [
-    {
-      name: 'e2e',
-      testMatch: /.*\.e2e\.spec\.ts/,
-      workers: 1, // One worker to allow shared Manager setup
-    },
-    {
-      name: 'component',
-      testMatch: /.*\.component\.spec\.ts/,
-      // Parallel execution allowed
-    },
-  ],
-});
-```
-
-The setup is based on the
-
-- Dev Server: `@openremote/test`
-- `playwright`
+The component tests are used to test individual Lit web components.
 
-##### Configuration
+#### Configuration
 
 The component tests run in parallel.
 
-- **Target:** UI packages (each component is a standalone NPM package).
-- **Runner App:** A dedicated app called `playwright` (used for component mounting).
+- **Target:** Any component in the `ui/component/*` directory.
+- **Runner App:** The component test setup includes a dedicated app at `ui/playwright` (used for component mounting).
 - **Testing Strategy:** Based on Playwright’s experimental component testing API, but adapted to Webpack using a custom plugin.
 
 ### End-to-End test setup
 
 The end-to-end tests are used to test app functionality from the frontend.
 
-##### Configuration
+#### Configuration
 
-The end-to-end tests run on sequentially using 1 worker to avoid tests interfering with each other.
+The end-to-end tests run sequentially using 1 worker to avoid tests interfering with each other.
 
-- **Target:** The `manager` app.
+- **Target:** Any app in the `ui/app` directory.
 - **Worker Scope:** Single worker (to avoid tests interfering with one-another).
-- **Fixtures:** Shared Manager fixture (`scope: 'worker'`) is used for initializing global resources like realm creation, auth sessions, etc.
+- **Fixtures:** The Manager app includes a `fixtures` directory with test and data fixtures (`scope: 'worker'`).
+- **Setup & Teardown:** The e2e test projects depend on the `*.setup.ts` and  `*.cleanup.ts` project files. These projects should be used to provision realm(s), user(s) and collect authentication states for more robust and performant tests.
+
+```ts
+function createAppSetupAndTeardown(app) {
+  return [
+    {
+      name: `setup ${app}`,
+      testMatch: "**/*.setup.ts",
+      teardown: `cleanup ${app}`,
+      worker: 1,
+    },
+    {
+      name: `cleanup ${app}`,
+      testMatch: "**/*.cleanup.ts",
+      worker: 1,
+    },
+  ];
+}
+```
 
 ## Writing tests
 
-**Component test**
+The best way to write tests using Playwright is by using the [Playwright UI mode](https://playwright.dev/docs/test-ui-mode). Start by adding a test directory if not already present in the project you want to test and add a test file ending in `*.test.ts`.
 
-**End-to-end test**
+**Component tests**
 
-Playwright uses [`locators`](https://playwright.dev/docs/locators) to find elements in the DOM. It's crucial to know the different types of locators to be able to write tests that are robust and to avoid flaky behaviour.
+Run the following command to open the component tests in Playwright UI mode.
+
+```sh
+npm test -- --ui
+```
 
-### Tips
+Component tests normally include the following boilerplate:
 
-#### Playwright features
+```ts
+import { ct } from "@openremote/test";
+
+import { MyComponent } from "@openremote/or-<my-component>";
+
+ct("My component test", async ({ mount }) => {
+  const component = await mount(MyComponent, {
+    props: { value: "test" },
+    // slots: {},
+    // on: {},
+  });
+  // await expect(component).toHaveValue("test");
+})
+```
 
-The most useful feature Playwright provides when it comes to writing frontend tests is [UI mode](https://playwright.dev/docs/test-ui-mode). Once the Playwright UI is launched you can select which projects you want to see and run.
+:::note
+You must import a component by its alias `@openremote/*`. Relative paths will cause issues. The downsides of the alias import is that this refers to the transpiled typescript `lib` directory, which you must manually update after making change to a component. You can update this using `gradle ui:component:my-component:npmBuild`.
+:::
 
-The UI includes a locator tab, which allows you to click an element in the test preview to get a selector.
+**End-to-end tests**
+
+The manager app or any app that you would want to test must first be running. The recommended way is to build the manager docker image first using `docker compose -p openremote -f profile/dev-ui.yml up -d --build`. Having the frontend be served by the manager is much faster than serving the frontend using Webpack.
+
+Then you can start the Playwright in UI mode using the following command.
 
 ```sh
-npm test -- --ui
 npm run e2e -- --ui
 ```
 
-In case you want to see how Playwright runs in a headed browser you can add the `--headed`.
+Playwright uses [`locators`](https://playwright.dev/docs/locators) to find elements in the DOM. It's crucial to know the different types of locators to be able to write tests that are robust and to avoid flaky behaviour.
+
+### Tips & Best practices
+
+The most useful feature Playwright provides when it comes to writing frontend tests is [UI mode](https://playwright.dev/docs/test-ui-mode). Once the Playwright UI is launched you can select which projects you want to see and run.
+
+:::tip
+The UI includes a locator tab, which allows you to click an element in the test preview to easily get a locator of an element.
+:::
+
+:::warning
+Sometimes the locators Playwright provides are suseptible to flaky behavior, it is important to understand the DOM structure of the UI to get the most affective locators.
+:::
+
+:::tip
+In some cases you may face a situation where the UI needs to load first before you can run an action. You can use `await selector.waitFor()` to ensure the element you want to interact with is visible.
+:::
+
+In case you want to see how Playwright runs in a headed browser you can add the `--headed` argument.
 
 ```sh
 npm run e2e -- --headed
@@ -99,12 +133,6 @@ npm run e2e -- --headed
 
 See https://playwright.dev/docs/test-cli#reference for more CLI arguments.
 
-#### Flaky tests
-
-Use `waitFor` and
-
-### Best practices
-
 Please read the [Playwright Best practices](https://playwright.dev/docs/best-practices).
 
 <!-- TODO: include what to do and what not to do -->
@@ -114,7 +142,5 @@ Please read the [Playwright Best practices](https://playwright.dev/docs/best-pra
 - Isolate tests, so you can rerun them without relying on external factors such as other tests.
 - Use [web first assertions](https://playwright.dev/docs/test-assertions) e.g. `toBeVisible`, `toBeHidden`, `toBeChecked` etc.
 - Reuse locators and actions through test fixtures
-- Use the test report, traces and debugger
+- Use the test reports, trace viewer and debugger
 <!-- - Enable multiple browsers (see playwright UI checkboxes) -->
-
-### Performance

From 3eac00b6896f31ce610b4c9476e05e036c4cb51a Mon Sep 17 00:00:00 2001
From: Ekhorn <koen@kschellingerhout.nl>
Date: Wed, 4 Jun 2025 09:17:53 +0200
Subject: [PATCH 03/15] Add prerequisites to writing tests

---
 docs/developer-guide/frontend-testing.md | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
index 7666e25..d5ca696 100644
--- a/docs/developer-guide/frontend-testing.md
+++ b/docs/developer-guide/frontend-testing.md
@@ -66,6 +66,18 @@ function createAppSetupAndTeardown(app) {
 
 ## Writing tests
 
+### Prerequisites
+
+Assumming you have setup your [development tooling](http://localhost:3000/docs/developer-guide/preparing-the-environment#development-tooling).
+
+Install the Playwright browsers:
+```sh
+npx playwright install --with-deps
+```
+See the [Playwright Intro](https://playwright.dev/docs/intro) for more.
+
+### Starting UI mode
+
 The best way to write tests using Playwright is by using the [Playwright UI mode](https://playwright.dev/docs/test-ui-mode). Start by adding a test directory if not already present in the project you want to test and add a test file ending in `*.test.ts`.
 
 **Component tests**

From 2456da6b3f6eb6edaba65b00f83525a5298ca02e Mon Sep 17 00:00:00 2001
From: Ekhorn <koen@kschellingerhout.nl>
Date: Wed, 4 Jun 2025 09:19:06 +0200
Subject: [PATCH 04/15] Separate best practices and tips section

---
 docs/developer-guide/frontend-testing.md | 28 +++++++++++++-----------
 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
index d5ca696..38f638d 100644
--- a/docs/developer-guide/frontend-testing.md
+++ b/docs/developer-guide/frontend-testing.md
@@ -121,7 +121,21 @@ npm run e2e -- --ui
 
 Playwright uses [`locators`](https://playwright.dev/docs/locators) to find elements in the DOM. It's crucial to know the different types of locators to be able to write tests that are robust and to avoid flaky behaviour.
 
-### Tips & Best practices
+### Best practices
+
+Please read the [Playwright Best practices](https://playwright.dev/docs/best-practices).
+
+<!-- TODO: include what to do and what not to do -->
+
+**TL;DR**
+- Avoid `xpath` and `css` selectors.
+- Isolate tests, so you can rerun them without relying on external factors such as other tests.
+- Use [web first assertions](https://playwright.dev/docs/test-assertions) e.g. `toBeVisible`, `toBeHidden`, `toBeChecked` etc.
+- Reuse locators and actions through test fixtures
+- Use the UI mode, test reports, trace viewer and debugger
+<!-- - Enable multiple browsers (see playwright UI checkboxes) -->
+
+### Tips
 
 The most useful feature Playwright provides when it comes to writing frontend tests is [UI mode](https://playwright.dev/docs/test-ui-mode). Once the Playwright UI is launched you can select which projects you want to see and run.
 
@@ -144,15 +158,3 @@ npm run e2e -- --headed
 ```
 
 See https://playwright.dev/docs/test-cli#reference for more CLI arguments.
-
-Please read the [Playwright Best practices](https://playwright.dev/docs/best-practices).
-
-<!-- TODO: include what to do and what not to do -->
-
-**TL;DR**
-- Avoid `xpath` and `css` selectors.
-- Isolate tests, so you can rerun them without relying on external factors such as other tests.
-- Use [web first assertions](https://playwright.dev/docs/test-assertions) e.g. `toBeVisible`, `toBeHidden`, `toBeChecked` etc.
-- Reuse locators and actions through test fixtures
-- Use the test reports, trace viewer and debugger
-<!-- - Enable multiple browsers (see playwright UI checkboxes) -->

From 7df62dc8341920d2cd31b7dadb836b21d3c533b4 Mon Sep 17 00:00:00 2001
From: Ekhorn <koen@kschellingerhout.nl>
Date: Wed, 4 Jun 2025 09:23:43 +0200
Subject: [PATCH 05/15] Fix typo

---
 docs/developer-guide/frontend-testing.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
index 38f638d..6a8330f 100644
--- a/docs/developer-guide/frontend-testing.md
+++ b/docs/developer-guide/frontend-testing.md
@@ -106,7 +106,7 @@ ct("My component test", async ({ mount }) => {
 ```
 
 :::note
-You must import a component by its alias `@openremote/*`. Relative paths will cause issues. The downsides of the alias import is that this refers to the transpiled typescript `lib` directory, which you must manually update after making change to a component. You can update this using `gradle ui:component:my-component:npmBuild`.
+You must import a component by its alias `@openremote/*`. Relative paths will cause issues. The downsides of the alias import is that this refers to the transpiled typescript `lib` directory, which you must manually update after making changes to a component. You can update this using `gradle ui:component:my-component:npmBuild`.
 :::
 
 **End-to-end tests**

From 392ed3680e6f65fb7d960e6f33792be036d0236b Mon Sep 17 00:00:00 2001
From: Ekhorn <koen@kschellingerhout.nl>
Date: Fri, 6 Jun 2025 06:54:28 +0200
Subject: [PATCH 06/15] Update best practices

---
 docs/developer-guide/frontend-testing.md | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
index 6a8330f..2778e79 100644
--- a/docs/developer-guide/frontend-testing.md
+++ b/docs/developer-guide/frontend-testing.md
@@ -125,14 +125,13 @@ Playwright uses [`locators`](https://playwright.dev/docs/locators) to find eleme
 
 Please read the [Playwright Best practices](https://playwright.dev/docs/best-practices).
 
-<!-- TODO: include what to do and what not to do -->
-
 **TL;DR**
-- Avoid `xpath` and `css` selectors.
+- Avoid `xpath` and `css` selectors. Relying to heavy on the [Document Object Model (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) makes you more prone to breaking tests when a CSS class is renamed or removed, or when nested elements are removed.
+- Do not use `waitForTimeout` outside of debugging. Tests don't always take the same amount of time which can cause flaky behavior, rather use something like `locator.waitFor()` or even better `page.waitForURL()`.
 - Isolate tests, so you can rerun them without relying on external factors such as other tests.
-- Use [web first assertions](https://playwright.dev/docs/test-assertions) e.g. `toBeVisible`, `toBeHidden`, `toBeChecked` etc.
-- Reuse locators and actions through test fixtures
-- Use the UI mode, test reports, trace viewer and debugger
+- Use [web first assertions](https://playwright.dev/docs/test-assertions) e.g. `toBeVisible`, `toBeHidden`, `toBeChecked` etc. use a retry mechanism to avoid flakiness.
+- Reuse locators and actions through test fixtures to set in stone how to locate specific elements on screen and avoid code duplication in tests.
+- Use the UI mode, test reports, trace viewer and debugger.
 <!-- - Enable multiple browsers (see playwright UI checkboxes) -->
 
 ### Tips

From 2b729df0eacb2cb3db2b04310af07d689082248e Mon Sep 17 00:00:00 2001
From: Ekhorn <koen@kschellingerhout.nl>
Date: Fri, 6 Jun 2025 16:22:29 +0200
Subject: [PATCH 07/15] Fix typos

---
 docs/developer-guide/frontend-testing.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
index 2778e79..1fdd72d 100644
--- a/docs/developer-guide/frontend-testing.md
+++ b/docs/developer-guide/frontend-testing.md
@@ -43,7 +43,7 @@ The end-to-end tests run sequentially using 1 worker to avoid tests interfering
 
 - **Target:** Any app in the `ui/app` directory.
 - **Worker Scope:** Single worker (to avoid tests interfering with one-another).
-- **Fixtures:** The Manager app includes a `fixtures` directory with test and data fixtures (`scope: 'worker'`).
+- **Fixtures:** The Manager app includes a `fixtures` directory with test and data fixtures.
 - **Setup & Teardown:** The e2e test projects depend on the `*.setup.ts` and  `*.cleanup.ts` project files. These projects should be used to provision realm(s), user(s) and collect authentication states for more robust and performant tests.
 
 ```ts
@@ -113,7 +113,7 @@ You must import a component by its alias `@openremote/*`. Relative paths will ca
 
 The manager app or any app that you would want to test must first be running. The recommended way is to build the manager docker image first using `docker compose -p openremote -f profile/dev-ui.yml up -d --build`. Having the frontend be served by the manager is much faster than serving the frontend using Webpack.
 
-Then you can start the Playwright in UI mode using the following command.
+Then you can start Playwright in UI mode using the following command.
 
 ```sh
 npm run e2e -- --ui
@@ -126,12 +126,12 @@ Playwright uses [`locators`](https://playwright.dev/docs/locators) to find eleme
 Please read the [Playwright Best practices](https://playwright.dev/docs/best-practices).
 
 **TL;DR**
-- Avoid `xpath` and `css` selectors. Relying to heavy on the [Document Object Model (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) makes you more prone to breaking tests when a CSS class is renamed or removed, or when nested elements are removed.
+- Avoid `xpath` and `css` selectors. Relying too heavy on the [Document Object Model (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) makes you more prone to breaking tests when a CSS class is renamed or removed, or when nested elements are removed.
 - Do not use `waitForTimeout` outside of debugging. Tests don't always take the same amount of time which can cause flaky behavior, rather use something like `locator.waitFor()` or even better `page.waitForURL()`.
 - Isolate tests, so you can rerun them without relying on external factors such as other tests.
-- Use [web first assertions](https://playwright.dev/docs/test-assertions) e.g. `toBeVisible`, `toBeHidden`, `toBeChecked` etc. use a retry mechanism to avoid flakiness.
-- Reuse locators and actions through test fixtures to set in stone how to locate specific elements on screen and avoid code duplication in tests.
-- Use the UI mode, test reports, trace viewer and debugger.
+- Use [web first assertions](https://playwright.dev/docs/test-assertions) e.g. `toBeVisible`, `toBeHidden`, `toBeChecked` etc. which use a retry mechanism to avoid flakiness.
+- Reuse locators and actions through test fixtures to standardize how to locate specific elements on screen and avoid code duplication in tests.
+- Use the Playwright UI mode, test reports, trace viewer and debugger features.
 <!-- - Enable multiple browsers (see playwright UI checkboxes) -->
 
 ### Tips
@@ -147,7 +147,7 @@ Sometimes the locators Playwright provides are suseptible to flaky behavior, it
 :::
 
 :::tip
-In some cases you may face a situation where the UI needs to load first before you can run an action. You can use `await selector.waitFor()` to ensure the element you want to interact with is visible.
+In some cases you may face a situation where the UI needs to load first, before you can run an action. You can use `await selector.waitFor()` to ensure the element you want to interact with is visible.
 :::
 
 In case you want to see how Playwright runs in a headed browser you can add the `--headed` argument.

From e17968e3f0d04b0f89373b35f354cc5c2ee096d8 Mon Sep 17 00:00:00 2001
From: Ekhorn <koen@kschellingerhout.nl>
Date: Wed, 25 Jun 2025 10:40:45 +0200
Subject: [PATCH 08/15] Fix docs URL and typos

---
 docs/developer-guide/frontend-testing.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
index 1fdd72d..05a43c3 100644
--- a/docs/developer-guide/frontend-testing.md
+++ b/docs/developer-guide/frontend-testing.md
@@ -19,7 +19,7 @@ We do this because we modify the base configuration that comes with the `defineC
 
 Both the `component` and `e2e` tests depend on the `@openremote/test` package which includes shared fixtures and our Playwright component testing plugin. Playwrights' component testing plugin comes with Vite, but this is incompatible with the `commonjs` imports used in some components. Playwright uses Vite to bundle and mount a component to an empty HTML document for testing. Our Playwright plugin mimics the Vite based plugin using Webpack so we can mount our components to the document without import issues.
 
-The `shared` fixture in the test package is meant for general test utilities like intercepting requests. The `components` fixture is specifically meant for utitilies related to components to share common actions between component- and E2E tests.
+The `shared` fixture in the test package is meant for general test utilities like intercepting requests. The `components` fixture is specifically meant for utilities related to components to share common actions between component- and E2E tests.
 
 ### Component test setup
 
@@ -68,7 +68,7 @@ function createAppSetupAndTeardown(app) {
 
 ### Prerequisites
 
-Assumming you have setup your [development tooling](http://localhost:3000/docs/developer-guide/preparing-the-environment#development-tooling).
+Assuming you have set up your [development tooling](preparing-the-environment#development-tooling).
 
 Install the Playwright browsers:
 ```sh
@@ -119,7 +119,7 @@ Then you can start Playwright in UI mode using the following command.
 npm run e2e -- --ui
 ```
 
-Playwright uses [`locators`](https://playwright.dev/docs/locators) to find elements in the DOM. It's crucial to know the different types of locators to be able to write tests that are robust and to avoid flaky behaviour.
+Playwright uses [`locators`](https://playwright.dev/docs/locators) to find elements in the DOM. It's crucial to know the different types of locators to be able to write tests that are robust and to avoid flaky behavior.
 
 ### Best practices
 
@@ -143,7 +143,7 @@ The UI includes a locator tab, which allows you to click an element in the test
 :::
 
 :::warning
-Sometimes the locators Playwright provides are suseptible to flaky behavior, it is important to understand the DOM structure of the UI to get the most affective locators.
+Sometimes the locators Playwright provides are susceptible to flaky behavior, it is important to understand the DOM structure of the UI to get the most affective locators.
 :::
 
 :::tip

From 863f73710514545a77be2eebb99d8fb5128674cd Mon Sep 17 00:00:00 2001
From: Ekhorn <koen@kschellingerhout.nl>
Date: Wed, 25 Jun 2025 11:26:11 +0200
Subject: [PATCH 09/15] Update naming conventions and commands in frontend
 testing guide

---
 docs/developer-guide/frontend-testing.md | 75 +++++++++++++++---------
 1 file changed, 48 insertions(+), 27 deletions(-)

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
index 05a43c3..968fd71 100644
--- a/docs/developer-guide/frontend-testing.md
+++ b/docs/developer-guide/frontend-testing.md
@@ -1,25 +1,37 @@
 # Frontend Testing
 
-OpenRemote uses [Playwright](https://playwright.dev/) for frontend-testing. Playwright was originally created for end-to-end testing i.e. testing through a browser just like how the user would interact with an application. This usually requires the backend to run, making them considerably slower than unit- or component tests. Playwright has added an experimental feature for component testing. Allowing you to use the same Playwright APIs on individual components for better test isolation and easier parallelization.
+OpenRemote uses [Playwright](https://playwright.dev/) for frontend-testing. Playwright was originally created for end-to-end testing i.e. testing through a browser just like how users would interact with an application. This usually requires the backend to run, making end-to-end tests considerably slower than unit- or component tests. Playwright has added an experimental feature for component testing. Allowing you to use the same Playwright APIs on individual components for better test isolation and easier parallelization.
 
 ## Test Organization
 
-The frontend tests are organized under `component` and `e2e` (end-to-end) tests.
+The frontend tests are organized under `app` (end-to-end) and `component` tests.
 
 ### General setup
 
-All frontend testing code is situated under the `ui` directory. We use different Playwright configurations for `component` and `e2e` testing.
+All frontend testing code is situated under the `ui` directory.
 
-- `ui/playwright-ct-config.ts`: Component testing configuration
-- `ui/playwright-config.ts`: End-to-end testing configuration
+We use different Playwright configurations for `app` and `component` testing.
 
-We do this because we modify the base configuration that comes with the `defineConfig` function for component testing to work, however this configuration is incompatible with E2E testing thus we use 2 configurations.
+- `ui/test/config/app.ts`: App test configuration
+- `ui/test/config/component.ts`: Component test configuration
+
+We do this because we modify the base configuration that comes with Playwright so that component testing works, however this configuration is incompatible with app testing thus we use 2 configurations.
 
 #### Shared test package
 
-Both the `component` and `e2e` tests depend on the `@openremote/test` package which includes shared fixtures and our Playwright component testing plugin. Playwrights' component testing plugin comes with Vite, but this is incompatible with the `commonjs` imports used in some components. Playwright uses Vite to bundle and mount a component to an empty HTML document for testing. Our Playwright plugin mimics the Vite based plugin using Webpack so we can mount our components to the document without import issues.
+Both the `app` and `component` tests depend on the `@openremote/test` package which includes shared fixtures, configurations and our Playwright component testing plugin.
+
+The `shared` fixture in the test package is meant for general test utilities like intercepting requests. The `components` fixture is specifically meant for utilities related to components to share common actions between app- and component tests.
+
+Each project that needs testing should configure the `npx playwright test` command under the `test` script in the `package.json` file and should have its own `playwright.config.ts` file with following contents.
+
+```ts
+import defineConfig from "@openremote/test/config/<app|component>";
+
+export default defineConfig(__dirname);
+```
 
-The `shared` fixture in the test package is meant for general test utilities like intercepting requests. The `components` fixture is specifically meant for utilities related to components to share common actions between component- and E2E tests.
+The plugin for component testing mimics Playwright’s component testing plugin, which normally comes with Vite, but this is incompatible with the `commonjs` imports used in some components. Playwright uses Vite to bundle and mount a component to an empty HTML document for testing. Our Playwright plugin mimics the Vite based plugin using Webpack so we can mount our components to the document without import issues.
 
 ### Component test setup
 
@@ -30,7 +42,7 @@ The component tests are used to test individual Lit web components.
 The component tests run in parallel.
 
 - **Target:** Any component in the `ui/component/*` directory.
-- **Runner App:** The component test setup includes a dedicated app at `ui/playwright` (used for component mounting).
+- **Runner App:** The component test setup includes a dedicated app at `ui/test/config/playwright` (used for component mounting).
 - **Testing Strategy:** Based on Playwright’s experimental component testing API, but adapted to Webpack using a custom plugin.
 
 ### End-to-End test setup
@@ -44,7 +56,7 @@ The end-to-end tests run sequentially using 1 worker to avoid tests interfering
 - **Target:** Any app in the `ui/app` directory.
 - **Worker Scope:** Single worker (to avoid tests interfering with one-another).
 - **Fixtures:** The Manager app includes a `fixtures` directory with test and data fixtures.
-- **Setup & Teardown:** The e2e test projects depend on the `*.setup.ts` and  `*.cleanup.ts` project files. These projects should be used to provision realm(s), user(s) and collect authentication states for more robust and performant tests.
+- **Setup & Teardown:** The e2e test projects depend on the `*.setup.ts` and `*.cleanup.ts` project files. These projects should be used to provision realm(s), user(s) and collect authentication states for more robust and performant tests.
 
 ```ts
 function createAppSetupAndTeardown(app) {
@@ -70,22 +82,43 @@ function createAppSetupAndTeardown(app) {
 
 Assuming you have set up your [development tooling](preparing-the-environment#development-tooling).
 
-Install the Playwright browsers:
+Make sure to include a `playwright.config.ts` file in the project you want to write tests for and the corresponding test script command(s):
+
+- The `app` test command: `npx playwright test`
+- The `component` test: `npx tsc -b && npx playwright test`
+
+Install the required Playwright browsers:
+
 ```sh
 npx playwright install --with-deps
 ```
+
 See the [Playwright Intro](https://playwright.dev/docs/intro) for more.
 
 ### Starting UI mode
 
 The best way to write tests using Playwright is by using the [Playwright UI mode](https://playwright.dev/docs/test-ui-mode). Start by adding a test directory if not already present in the project you want to test and add a test file ending in `*.test.ts`.
 
+**App tests**
+
+The manager app or any app that you would want to test must first be running. The recommended way is to build the manager docker image first using `docker compose -p openremote -f profile/dev-ui.yml up -d --build`. Having the frontend be served by the manager is much faster than serving the frontend using Webpack.
+
+Then you can start Playwright in UI mode using the Gradle task.
+
+```sh
+gradle ui:app:manager:npmTestUI
+# Or run npm test -- --ui in the corresponding directory
+```
+
+Playwright uses [`locators`](https://playwright.dev/docs/locators) to find elements in the DOM. It's crucial to know the different types of locators to be able to write tests that are robust and to avoid flaky behavior.
+
 **Component tests**
 
-Run the following command to open the component tests in Playwright UI mode.
+Run the following task to open the component tests in Playwright UI mode.
 
 ```sh
-npm test -- --ui
+gradle ui:component:or-component:npmTestUI
+# Or run npm test -- --ui in the corresponding directory
 ```
 
 Component tests normally include the following boilerplate:
@@ -106,21 +139,9 @@ ct("My component test", async ({ mount }) => {
 ```
 
 :::note
-You must import a component by its alias `@openremote/*`. Relative paths will cause issues. The downsides of the alias import is that this refers to the transpiled typescript `lib` directory, which you must manually update after making changes to a component. You can update this using `gradle ui:component:my-component:npmBuild`.
+You must import a component by its alias `@openremote/*`. Relative paths will cause issues. The downsides of the alias import is that this refers to the transpiled typescript `lib` directory, which is why the component test script includes `npx tsc -b`.
 :::
 
-**End-to-end tests**
-
-The manager app or any app that you would want to test must first be running. The recommended way is to build the manager docker image first using `docker compose -p openremote -f profile/dev-ui.yml up -d --build`. Having the frontend be served by the manager is much faster than serving the frontend using Webpack.
-
-Then you can start Playwright in UI mode using the following command.
-
-```sh
-npm run e2e -- --ui
-```
-
-Playwright uses [`locators`](https://playwright.dev/docs/locators) to find elements in the DOM. It's crucial to know the different types of locators to be able to write tests that are robust and to avoid flaky behavior.
-
 ### Best practices
 
 Please read the [Playwright Best practices](https://playwright.dev/docs/best-practices).
@@ -153,7 +174,7 @@ In some cases you may face a situation where the UI needs to load first, before
 In case you want to see how Playwright runs in a headed browser you can add the `--headed` argument.
 
 ```sh
-npm run e2e -- --headed
+npm run test -- --headed
 ```
 
 See https://playwright.dev/docs/test-cli#reference for more CLI arguments.

From e70c52d919cfce141d6d650b1e3b92f2b6a91352 Mon Sep 17 00:00:00 2001
From: Ekhorn <koen@kschellingerhout.nl>
Date: Wed, 25 Jun 2025 11:45:21 +0200
Subject: [PATCH 10/15] Fix playwright config and test script documentation

---
 docs/developer-guide/frontend-testing.md | 24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
index 968fd71..0d133e0 100644
--- a/docs/developer-guide/frontend-testing.md
+++ b/docs/developer-guide/frontend-testing.md
@@ -23,13 +23,7 @@ Both the `app` and `component` tests depend on the `@openremote/test` package wh
 
 The `shared` fixture in the test package is meant for general test utilities like intercepting requests. The `components` fixture is specifically meant for utilities related to components to share common actions between app- and component tests.
 
-Each project that needs testing should configure the `npx playwright test` command under the `test` script in the `package.json` file and should have its own `playwright.config.ts` file with following contents.
-
-```ts
-import defineConfig from "@openremote/test/config/<app|component>";
-
-export default defineConfig(__dirname);
-```
+Each project that needs testing should configure its own Playwright configuration file which must reuse the above-mentioned configurations.
 
 The plugin for component testing mimics Playwright’s component testing plugin, which normally comes with Vite, but this is incompatible with the `commonjs` imports used in some components. Playwright uses Vite to bundle and mount a component to an empty HTML document for testing. Our Playwright plugin mimics the Vite based plugin using Webpack so we can mount our components to the document without import issues.
 
@@ -82,10 +76,20 @@ function createAppSetupAndTeardown(app) {
 
 Assuming you have set up your [development tooling](preparing-the-environment#development-tooling).
 
-Make sure to include a `playwright.config.ts` file in the project you want to write tests for and the corresponding test script command(s):
+Make sure to include the corresponding playwright configuration and test script command(s):
+
+|           | config                    | test script (in package.json)                                        |
+| --------- | ------------------------- | -------------------------------------------------------------------- |
+| app       | `playwright.config.ts`    | `npx playwright test`                                                |
+| component | `playwright-ct.config.ts` | `npx tsc -b && npx playwright test --config playwright-ct.config.ts` |
 
-- The `app` test command: `npx playwright test`
-- The `component` test: `npx tsc -b && npx playwright test`
+Configuration contents:
+
+```ts
+import defineConfig from "@openremote/test/config/<app|component>";
+
+export default defineConfig(__dirname);
+```
 
 Install the required Playwright browsers:
 

From 1a5115d450fdf444036180c45ce4b654c61f166f Mon Sep 17 00:00:00 2001
From: Ekhorn <koen@kschellingerhout.nl>
Date: Mon, 30 Jun 2025 13:48:15 +0200
Subject: [PATCH 11/15] Specify required browser to install

---
 docs/developer-guide/frontend-testing.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
index 0d133e0..a40d862 100644
--- a/docs/developer-guide/frontend-testing.md
+++ b/docs/developer-guide/frontend-testing.md
@@ -94,7 +94,7 @@ export default defineConfig(__dirname);
 Install the required Playwright browsers:
 
 ```sh
-npx playwright install --with-deps
+npx playwright install --with-deps chromium
 ```
 
 See the [Playwright Intro](https://playwright.dev/docs/intro) for more.

From b6e17b0014f2d16af6b3a7ddbf43db7fec2c36c5 Mon Sep 17 00:00:00 2001
From: Ekhorn <koen@kschellingerhout.nl>
Date: Fri, 11 Jul 2025 14:07:08 +0200
Subject: [PATCH 12/15] Update frontend testing guide

---
 docs/developer-guide/frontend-testing.md | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
index a40d862..cc98754 100644
--- a/docs/developer-guide/frontend-testing.md
+++ b/docs/developer-guide/frontend-testing.md
@@ -12,8 +12,8 @@ All frontend testing code is situated under the `ui` directory.
 
 We use different Playwright configurations for `app` and `component` testing.
 
-- `ui/test/config/app.ts`: App test configuration
-- `ui/test/config/component.ts`: Component test configuration
+- `ui/test/app.config.ts`: App test configuration
+- `ui/test/component.config.ts`: Component test configuration
 
 We do this because we modify the base configuration that comes with Playwright so that component testing works, however this configuration is incompatible with app testing thus we use 2 configurations.
 
@@ -21,7 +21,7 @@ We do this because we modify the base configuration that comes with Playwright s
 
 Both the `app` and `component` tests depend on the `@openremote/test` package which includes shared fixtures, configurations and our Playwright component testing plugin.
 
-The `shared` fixture in the test package is meant for general test utilities like intercepting requests. The `components` fixture is specifically meant for utilities related to components to share common actions between app- and component tests.
+The `shared` fixture in the test package is meant for general test utilities like intercepting requests.
 
 Each project that needs testing should configure its own Playwright configuration file which must reuse the above-mentioned configurations.
 
@@ -33,11 +33,11 @@ The component tests are used to test individual Lit web components.
 
 #### Configuration
 
-The component tests run in parallel.
+Each component runs its own tests in parallel.
 
 - **Target:** Any component in the `ui/component/*` directory.
-- **Runner App:** The component test setup includes a dedicated app at `ui/test/config/playwright` (used for component mounting).
-- **Testing Strategy:** Based on Playwright’s experimental component testing API, but adapted to Webpack using a custom plugin.
+- **Runner App:** The component test setup includes a dedicated app at `ui/test/playwright` (used to display components and serving static files).
+- **Testing Strategy:** Based on Playwright’s experimental component testing API, but adapted to Webpack using a custom plugin. Each component may include a `fixtures` directory which can provide reusable test code for other components and apps.
 
 ### End-to-End test setup
 
@@ -86,7 +86,7 @@ Make sure to include the corresponding playwright configuration and test script
 Configuration contents:
 
 ```ts
-import defineConfig from "@openremote/test/config/<app|component>";
+import defineConfig from "@openremote/test/<app|component>.config";
 
 export default defineConfig(__dirname);
 ```
@@ -101,7 +101,7 @@ See the [Playwright Intro](https://playwright.dev/docs/intro) for more.
 
 ### Starting UI mode
 
-The best way to write tests using Playwright is by using the [Playwright UI mode](https://playwright.dev/docs/test-ui-mode). Start by adding a test directory if not already present in the project you want to test and add a test file ending in `*.test.ts`.
+The best way to write tests using Playwright is by using the [Playwright UI mode](https://playwright.dev/docs/test-ui-mode) feature. Start by adding a test directory if not already present in the project you want to test and add a test file ending in `*.test.ts`.
 
 **App tests**
 
@@ -138,7 +138,7 @@ ct("My component test", async ({ mount }) => {
     // slots: {},
     // on: {},
   });
-  // await expect(component).toHaveValue("test");
+  await expect(component).toHaveValue("test");
 })
 ```
 

From 07f6c1d1109d7784a9c5e02dc2eee1b3b93d3b4c Mon Sep 17 00:00:00 2001
From: Ekhorn <44117179+Ekhorn@users.noreply.github.com>
Date: Fri, 15 Aug 2025 17:41:07 +0200
Subject: [PATCH 13/15] Apply suggestions from code review

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
---
 docs/developer-guide/frontend-testing.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
index cc98754..8de1ca2 100644
--- a/docs/developer-guide/frontend-testing.md
+++ b/docs/developer-guide/frontend-testing.md
@@ -1,6 +1,6 @@
 # Frontend Testing
 
-OpenRemote uses [Playwright](https://playwright.dev/) for frontend-testing. Playwright was originally created for end-to-end testing i.e. testing through a browser just like how users would interact with an application. This usually requires the backend to run, making end-to-end tests considerably slower than unit- or component tests. Playwright has added an experimental feature for component testing. Allowing you to use the same Playwright APIs on individual components for better test isolation and easier parallelization.
+OpenRemote uses [Playwright](https://playwright.dev/) for frontend testing. Playwright was originally created for end-to-end testing i.e. testing through a browser just like how users would interact with an application. This usually requires the backend to run, making end-to-end tests considerably slower than unit- or component tests. Playwright has added an experimental feature for component testing. Allowing you to use the same Playwright APIs on individual components for better test isolation and easier parallelization.
 
 ## Test Organization
 
@@ -151,7 +151,7 @@ You must import a component by its alias `@openremote/*`. Relative paths will ca
 Please read the [Playwright Best practices](https://playwright.dev/docs/best-practices).
 
 **TL;DR**
-- Avoid `xpath` and `css` selectors. Relying too heavy on the [Document Object Model (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) makes you more prone to breaking tests when a CSS class is renamed or removed, or when nested elements are removed.
+- Avoid `xpath` and `css` selectors. Relying too heavily on the [Document Object Model (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) makes you more prone to breaking tests when a CSS class is renamed or removed, or when nested elements are removed.
 - Do not use `waitForTimeout` outside of debugging. Tests don't always take the same amount of time which can cause flaky behavior, rather use something like `locator.waitFor()` or even better `page.waitForURL()`.
 - Isolate tests, so you can rerun them without relying on external factors such as other tests.
 - Use [web first assertions](https://playwright.dev/docs/test-assertions) e.g. `toBeVisible`, `toBeHidden`, `toBeChecked` etc. which use a retry mechanism to avoid flakiness.
@@ -168,7 +168,7 @@ The UI includes a locator tab, which allows you to click an element in the test
 :::
 
 :::warning
-Sometimes the locators Playwright provides are susceptible to flaky behavior, it is important to understand the DOM structure of the UI to get the most affective locators.
+Sometimes the locators Playwright provides are susceptible to flaky behavior, it is important to understand the DOM structure of the UI to get the most effective locators.
 :::
 
 :::tip

From c9b869e825f6fa9fb533e7d9b3fa2257e380b4ee Mon Sep 17 00:00:00 2001
From: Ekhorn <44117179+Ekhorn@users.noreply.github.com>
Date: Thu, 21 Aug 2025 10:48:37 +0200
Subject: [PATCH 14/15] Update Webpack references with Rspack

---
 docs/developer-guide/frontend-testing.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
index 8de1ca2..9c5458d 100644
--- a/docs/developer-guide/frontend-testing.md
+++ b/docs/developer-guide/frontend-testing.md
@@ -25,7 +25,7 @@ The `shared` fixture in the test package is meant for general test utilities lik
 
 Each project that needs testing should configure its own Playwright configuration file which must reuse the above-mentioned configurations.
 
-The plugin for component testing mimics Playwright’s component testing plugin, which normally comes with Vite, but this is incompatible with the `commonjs` imports used in some components. Playwright uses Vite to bundle and mount a component to an empty HTML document for testing. Our Playwright plugin mimics the Vite based plugin using Webpack so we can mount our components to the document without import issues.
+The plugin for component testing mimics Playwright’s component testing plugin, which normally comes with Vite, but this is incompatible with the `commonjs` imports used in some components. Playwright uses Vite to bundle and mount a component to an empty HTML document for testing. Our Playwright plugin mimics the Vite based plugin using Rspack so we can mount our components to the document without import issues.
 
 ### Component test setup
 
@@ -37,7 +37,7 @@ Each component runs its own tests in parallel.
 
 - **Target:** Any component in the `ui/component/*` directory.
 - **Runner App:** The component test setup includes a dedicated app at `ui/test/playwright` (used to display components and serving static files).
-- **Testing Strategy:** Based on Playwright’s experimental component testing API, but adapted to Webpack using a custom plugin. Each component may include a `fixtures` directory which can provide reusable test code for other components and apps.
+- **Testing Strategy:** Based on Playwright’s experimental component testing API, but adapted to Rspack using a custom plugin. Each component may include a `fixtures` directory which can provide reusable test code for other components and apps.
 
 ### End-to-End test setup
 
@@ -105,7 +105,7 @@ The best way to write tests using Playwright is by using the [Playwright UI mode
 
 **App tests**
 
-The manager app or any app that you would want to test must first be running. The recommended way is to build the manager docker image first using `docker compose -p openremote -f profile/dev-ui.yml up -d --build`. Having the frontend be served by the manager is much faster than serving the frontend using Webpack.
+The manager app or any app that you would want to test must first be running. The recommended way is to build the manager docker image first using `docker compose -p openremote -f profile/dev-ui.yml up -d --build`. Having the frontend be served by the manager is much faster than serving the frontend using Rspack.
 
 Then you can start Playwright in UI mode using the Gradle task.
 

From c6a463f29d4dd73992fb73d305ef35915e3c0056 Mon Sep 17 00:00:00 2001
From: Ekhorn <44117179+Ekhorn@users.noreply.github.com>
Date: Thu, 21 Aug 2025 10:49:40 +0200
Subject: [PATCH 15/15] Wrap gradle task example with brackets

---
 docs/developer-guide/frontend-testing.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/developer-guide/frontend-testing.md b/docs/developer-guide/frontend-testing.md
index 9c5458d..9555ac1 100644
--- a/docs/developer-guide/frontend-testing.md
+++ b/docs/developer-guide/frontend-testing.md
@@ -121,7 +121,7 @@ Playwright uses [`locators`](https://playwright.dev/docs/locators) to find eleme
 Run the following task to open the component tests in Playwright UI mode.
 
 ```sh
-gradle ui:component:or-component:npmTestUI
+gradle ui:component:or-<my-component>:npmTestUI
 # Or run npm test -- --ui in the corresponding directory
 ```
 
