test-placement

Name: test-placement
Author: redhat-developer

15stars31forks

How to install test-placement?

redhat-developer/rhdh-skill/test-placement

$npx -y skills add redhat-developer/rhdh-skill --skill test-placement

Installs into the current project.

Summary

Propose where to test a change in the RHDH dynamic-plugin ecosystem: which repo (rhdh-plugins, rhdh-plugin-export-overlays, rhdh), which test layer (unit, integration, component, cluster-free E2E, cluster E2E), where the test lives, and how to create it. Use when asked "where sho

Files · 1

View on GitHub

SKILL.md

1	# Test Placement Advisor
2
3	Given the context of a change, bug, or new feature in the RHDH dynamic-plugin ecosystem, propose where it should be tested: which repository, which test layer, where the test lives, and how to create it. The guiding rule: pick the cheapest environment that can actually catch the bug — most plugin validation does not need a cluster, and an increasing part doesn't need Docker either.
4
5	Conventions in this skill: paths are prefixed with the repo they live in — `rhdh:`, `overlays:` (= rhdh-plugin-export-overlays), `plugins:` (= rhdh-plugins). For broader repo context, consult `../rhdh/references/rhdh-repos.md` (requires the `rhdh` core skill installed alongside; skip if the file is not found). Some harnesses referenced here are still in review (see References for PR status). Before recommending a harness or script, verify its path exists on the target repo's `main`; if it doesn't, tell the developer it is pending in the corresponding PR instead of asserting it exists.
6
7	## When to Use
8
9	- A new plugin, plugin version bump, or plugin config change needs test coverage.
10	- A bug escaped to a cluster e2e run and the team wants a cheaper regression test.
11	- Reviewing a PR that adds a test at the wrong layer (e.g. a cluster e2e for pure UI logic).
12
13	## Step 1 — Gather context (ask if missing)
14
15	Before recommending, establish:
16
17	1. What is being validated? Plugin logic/UI component · packaging/published artifact · plugin loading/rendering inside RHDH · platform behavior (Helm/Operator/ingress/auth).
18	2. Where did the change happen? Plugin source (`rhdh-plugins` or another source repo) · packaging metadata (`rhdh-plugin-export-overlays`) · the RHDH app itself (`rhdh`).
19	3. Does verifying it require a rendered UI? (clicks, headings, navigation)
20	4. Does it require real external services? (GitHub, Keycloak, LDAP, managed DBs)
21	5. Does it require cluster infrastructure? (ConfigMap reload, routes, operator, pod logs, port-forward)
22
23	## Step 2 — Decision table
24
25	\| The dev wants to verify… \| Repo \| Test type / harness \| Cluster? \| Docker? \|
26	\| --- \| --- \| --- \| --- \| --- \|
27	\| Plugin logic / components / API \| `rhdh-plugins` (or the plugin's source repo) \| unit + component tests, dev app (`yarn start`) \| no \| no \|
28	\| The plugin still builds as a dynamic plugin \| `rhdh-plugins` \| `npx @red-hat-developer-hub/cli plugin export` \| no \| no \|
29	\| The published OCI artifact installs and the backend plugin boots \| `rhdh-plugin-export-overlays` \| native smoke harness (`overlays: smoke-tests-native/`) \| no \| no \|
30	\| All plugins of a workspace boot together \| `rhdh-plugin-export-overlays` \| native smoke with a `dynamic-plugins.yaml` listing the workspace's `oci://` refs \| no \| no \|
31	\| A frontend artifact ships its bundle (`dist-scalprum/`, `plugin-manifest.json`) \| `rhdh-plugin-export-overlays` \| native smoke presence check \| no \| no \|
32	\| The plugin loads inside the real RHDH app and the UI renders \| `rhdh` \| cluster-free E2E harness (`rhdh: e2e-tests/playwright.legacy-local.config.ts`, script `e2e:legacy-local`) \| no \| no \|
33	\| Every plugin in the catalog index is sane \| `rhdh` \| catalog-index plugin sanity check (nightly) \| no \| no \|
34	\| RHDH container behavior (image entrypoint, install script inside the image) \| `rhdh-plugin-export-overlays` (artifacts) / any (manual) \| Docker smoke (`overlays: smoke-tests/` + workflow `run-workspace-smoke-tests.yaml`) · manual: [rhdh-local](https://github.com/redhat-developer/rhdh-local) \| no \| yes \|
35	\| Helm chart / Operator / ingress / real Keycloak / RBAC on OCP \| `rhdh` e2e or `overlays: workspaces//e2e-tests` \| cluster e2e \| yes* \| n/a (cluster) \|
36
37	Rule of thumb: source bugs → rhdh-plugins · artifact bugs → overlays · integration/render bugs → rhdh · platform bugs → cluster e2e. If a bug is catchable in more than one place, test it in the cheapest one and don't duplicate downstream.
38
39	## Step 3 — Layer ladder (cheapest that catches the bug wins)
40
41	\| Layer \| Scope \| Tooling \| Cluster \| Typical time \|
42	\| --- \| --- \| --- \| --- \| --- \|
43	\| L1 Unit \| Pure functions / logic \| Jest/Vitest \| no \| ms–s \|
44	\| L2 Integration \| Backend module + plugin API, mocked external deps \| `startTestBackend` + supertest \| no \| s \|
45	\| L3 Component \| React component/page with a test harness \| RTL + dev server \| no \| s–min \|
46	\| L4a E2E cluster-free \| Full app, no managed infra \| Playwright + local harne

People who liked this also viewed

6 picks

Type

test-placement

15stars31forks

View on GitHub

How to install test-placement?

redhat-developer/rhdh-skill/test-placement

$npx -y skills add redhat-developer/rhdh-skill --skill test-placement

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Test Placement Advisor
2
3	Given the context of a change, bug, or new feature in the RHDH dynamic-plugin ecosystem, propose where it should be tested: which repository, which test layer, where the test lives, and how to create it. The guiding rule: pick the cheapest environment that can actually catch the bug — most plugin validation does not need a cluster, and an increasing part doesn't need Docker either.
4
5	Conventions in this skill: paths are prefixed with the repo they live in — `rhdh:`, `overlays:` (= rhdh-plugin-export-overlays), `plugins:` (= rhdh-plugins). For broader repo context, consult `../rhdh/references/rhdh-repos.md` (requires the `rhdh` core skill installed alongside; skip if the file is not found). Some harnesses referenced here are still in review (see References for PR status). Before recommending a harness or script, verify its path exists on the target repo's `main`; if it doesn't, tell the developer it is pending in the corresponding PR instead of asserting it exists.
6
7	## When to Use
8
9	- A new plugin, plugin version bump, or plugin config change needs test coverage.
10	- A bug escaped to a cluster e2e run and the team wants a cheaper regression test.
11	- Reviewing a PR that adds a test at the wrong layer (e.g. a cluster e2e for pure UI logic).
12
13	## Step 1 — Gather context (ask if missing)
14
15	Before recommending, establish:
16
17	1. What is being validated? Plugin logic/UI component · packaging/published artifact · plugin loading/rendering inside RHDH · platform behavior (Helm/Operator/ingress/auth).
18	2. Where did the change happen? Plugin source (`rhdh-plugins` or another source repo) · packaging metadata (`rhdh-plugin-export-overlays`) · the RHDH app itself (`rhdh`).
19	3. Does verifying it require a rendered UI? (clicks, headings, navigation)
20	4. Does it require real external services? (GitHub, Keycloak, LDAP, managed DBs)
21	5. Does it require cluster infrastructure? (ConfigMap reload, routes, operator, pod logs, port-forward)
22
23	## Step 2 — Decision table
24
25	\| The dev wants to verify… \| Repo \| Test type / harness \| Cluster? \| Docker? \|
26	\| --- \| --- \| --- \| --- \| --- \|
27	\| Plugin logic / components / API \| `rhdh-plugins` (or the plugin's source repo) \| unit + component tests, dev app (`yarn start`) \| no \| no \|
28	\| The plugin still builds as a dynamic plugin \| `rhdh-plugins` \| `npx @red-hat-developer-hub/cli plugin export` \| no \| no \|
29	\| The published OCI artifact installs and the backend plugin boots \| `rhdh-plugin-export-overlays` \| native smoke harness (`overlays: smoke-tests-native/`) \| no \| no \|
30	\| All plugins of a workspace boot together \| `rhdh-plugin-export-overlays` \| native smoke with a `dynamic-plugins.yaml` listing the workspace's `oci://` refs \| no \| no \|
31	\| A frontend artifact ships its bundle (`dist-scalprum/`, `plugin-manifest.json`) \| `rhdh-plugin-export-overlays` \| native smoke presence check \| no \| no \|
32	\| The plugin loads inside the real RHDH app and the UI renders \| `rhdh` \| cluster-free E2E harness (`rhdh: e2e-tests/playwright.legacy-local.config.ts`, script `e2e:legacy-local`) \| no \| no \|
33	\| Every plugin in the catalog index is sane \| `rhdh` \| catalog-index plugin sanity check (nightly) \| no \| no \|
34	\| RHDH container behavior (image entrypoint, install script inside the image) \| `rhdh-plugin-export-overlays` (artifacts) / any (manual) \| Docker smoke (`overlays: smoke-tests/` + workflow `run-workspace-smoke-tests.yaml`) · manual: [rhdh-local](https://github.com/redhat-developer/rhdh-local) \| no \| yes \|
35	\| Helm chart / Operator / ingress / real Keycloak / RBAC on OCP \| `rhdh` e2e or `overlays: workspaces//e2e-tests` \| cluster e2e \| yes* \| n/a (cluster) \|
36
37	Rule of thumb: source bugs → rhdh-plugins · artifact bugs → overlays · integration/render bugs → rhdh · platform bugs → cluster e2e. If a bug is catchable in more than one place, test it in the cheapest one and don't duplicate downstream.
38
39	## Step 3 — Layer ladder (cheapest that catches the bug wins)
40
41	\| Layer \| Scope \| Tooling \| Cluster \| Typical time \|
42	\| --- \| --- \| --- \| --- \| --- \|
43	\| L1 Unit \| Pure functions / logic \| Jest/Vitest \| no \| ms–s \|
44	\| L2 Integration \| Backend module + plugin API, mocked external deps \| `startTestBackend` + supertest \| no \| s \|
45	\| L3 Component \| React component/page with a test harness \| RTL + dev server \| no \| s–min \|
46	\| L4a E2E cluster-free \| Full app, no managed infra \| Playwright + local harne

People who liked this also viewed

6 picks

Type