ci: 60 unit specs across 8 Angular plugin repos are never run by any pipeline

[renemadsen]

60 unit spec files across 8 Angular plugin repos are never executed by any CI pipeline. They compile-rot silently: nothing notices when a component they cover changes, and nothing notices when the spec itself stops being valid.

Found while auditing why a spec written for a shared component appeared to run nowhere. (That particular fear was unfounded — eform-angular-frontend does run Jest, via the test-angular-unit job. These eight repos are the real gap.)

Who runs their unit specs today

Repo	Unit specs	Runs in CI
eform-angular-frontend (core)	35	yes — test-angular-unit job
eform-backendconfiguration-plugin	35	yes — plugin-scoped npx jest step
eform-kanban-plugin	19	yes
eform-angular-timeplanning-plugin	14	yes
eform-angular-insight-dashboard-plugin	22	no
eform-angular-eform-dashboard-plugin	15	no
eform-angular-inventory-plugin	8	no
eform-angular-items-planning-plugin	6	no
eform-angular-work-orders-plugin	5	no
eform-angular-workflow-plugin	2	no
eform-angular-chemical-plugin	1	no
eform-angular-appointment-plugin	1	no

(Counts exclude e2e/, playwright/, cypress/ and node_modules.)

Why they cannot simply be run in place

None of the eight has a jest.config. An Angular plugin repo holds only its module sources; the Jest preset, setup-jest.ts, the moduleNameMapper and tsconfig.spec.json all live in eform-angular-frontend/eform-client. So npx jest inside a plugin repo has nothing to run with.

The mechanism that already works

eform-backendconfiguration-plugin solved this. Its workflow checks out the frontend, copies the plugin in, and runs the frontend's Jest scoped to its own path (.github/workflows/dotnet-core-pr.yml:343):

- name: Run Jest unit tests
  run: cd eform-angular-frontend/eform-client && npx jest --ci --maxWorkers=2 "src/app/plugins/modules/backend-configuration-pn/"

The trailing positional argument is a path regex, so the run is scoped to that plugin's specs and cannot collide with the core job or another plugin's.

Each of the eight repos already checks out the frontend and installs its dependencies for the Playwright/e2e jobs, so in most cases this is one step added to an existing job, not new infrastructure.

Important unknown — do not skip this

Whether these 60 specs currently pass is unverified. They have not been executed in a long time, if ever. Some are likely to be stale — the platform has moved through several Angular majors, and specs elsewhere in the tree still import async from @angular/core/testing, which was removed.

So this is not a "flip it on everywhere" change. Per repo:

1. Add the step and run it.
2. If it is green, merge — that repo is done.
3. If it is red, decide per spec: fix it, or delete it. A spec that no longer reflects the code is worse than no spec, because it looks like coverage.

Do the repos in ascending order of spec count (appointment/chemical/workflow first) to find the shape of the problem cheaply before committing to insight-dashboard's 22.

Worth knowing

master on these repos is not branch-protected, so a newly-added job cannot block a merge until required status checks are configured. Enabling the job still surfaces failures on the PR page; it just does not gate. That is a separate decision, but it caps the value of this work and is worth settling alongside it.

Acceptance criteria

• Every Angular plugin repo with unit specs runs them in CI, scoped to its own plugin path.
• Every such job is green — by fixing or deleting stale specs, with the deletions justified rather than silent.
• A new plugin repo added later inherits the step (document it wherever the plugin CI template lives).