- Home
- Skills
- Wellapp Ai
- Well
- Test Hardening
test-hardening_skill
- TypeScript
306
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill wellapp-ai/well --skill test-hardening- SKILL.md5.2 KB
Overview
This skill converts verified QA Contract criteria (G#N and AC#N) into permanent automated tests so passing scenarios become regression checks. It produces Jest backend tests, Storybook state stories, and Playwright end-to-end specs, then runs the suites to confirm tests pass.
How this skill works
The skill ingests a Verification Report listing passed G#N scenarios and AC#N acceptance criteria. It categorizes each criterion by test type, checks for existing tests, and generates missing Jest tests, Storybook stories, or Playwright specs using standardized templates. Finally it runs the relevant test runner commands and produces a Test Hardening Report summarizing created files and results.
When to use it
- After qa-commit returns GREEN for a commit
- After a debug session fixes an issue (Phase 7: Harden)
- Before merging a PR to ensure all verified criteria have tests
- Manually when you want to convert verified criteria into regressions
- During release prep to lock verified behaviors into tests
Best practices
- Include the original criterion ID (G#N or AC#N) as a comment in each generated test
- Prefer small, focused tests that assert one behavior per case
- Skip generation when an existing test already references the scenario or criterion
- Run the specific test runner (Jest/Storybook/Playwright) after generation to ensure tests are passing
- Add a brief regression note linking to the debug session or issue when hardening a bug fix
Example use cases
- A backend API G#3 that returned correct invoice totals is converted into a Jest test under apps/api/**/__tests__
- A UI AC#2 that describes the loading state is added as a Storybook story variant for the component
- An interaction AC#5 (form submission) becomes a Playwright spec in tests/e2e to prevent regressions
- After a debug session reproduces a flaky invoice-parsing bug, generate a regression test referencing the debug steps
- Before pushing a release, run the skill to ensure every green QA criterion has an automated test
FAQ
A Verification Report listing passed G#N scenarios and AC#N acceptance criteria, plus access to the repository to add files.
Which frameworks and file locations are used?
Backend G#N → Jest (apps/api/**/*.test.ts). State AC#N → Storybook stories (**/*.stories.tsx). Interaction AC#N → Playwright (tests/e2e/**/*.spec.ts).
How does it avoid duplicating tests?
It searches test files for the scenario or criterion marker and skips generation if a matching test or story already exists.