test-generate
Skill6 starsChanged 28 days agoMITView on GitHub
Fill the test gap for an existing module. Five test types covered: - Discovery first. Before generating, scan the module to know exactly what's missing. Do not overwrite existing tests unless --overwrite is set. - Real assertions only. Every generated test must contain at least one real assertion. Empty stubs and markTestIncomplete() calls are forbidden. - Static-check every file. Run php -l on every PHP test file, xmllint on every MFTF file, node --check on every JS test before reporting…
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 2 are distinctive, and 9 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 26
Discovery first: Before generating, scan the module to know exactly what's missing.
- Very specific: line 27
Do not overwrite existing tests unless --overwrite is set.
- Very specific: line 28
Real assertions only: Every generated test must contain at least one real assertion.
- Very specific: line 30
Static-check every file: Run php -l on every PHP test file, xmllint on every MFTF file, node --check on every JS test before reporting done.
- Very specific: line 35
Type-safe mocks: Use MockObject&InterfaceName typing on every mock property.
- Very specific: line 40
Output budget: Follow context/references/output-budget.md — targeted reads, summary-first test/lint output, long logs to files.
- Very specific: line 107
Run unit tests via {ctx.runner} vendor/bin/phpunit {paths}.
- Distinctive: line 108
Run integration tests if Magento install available.
- Very specific: line 109
Apply the shared module-hygiene baseline (required): After generating the test PHP files, run …
- Distinctive: line 200
Every generated test contains at least one real assertion.
- Very specific: line 201
Every PHP test passes php -l.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Magento 2 Test Generate
Fill the test gap for an existing module. Five test types covered:
| Test type | When generated |
| Unit | For every Api/, Service/, Model/, Plugin/, Observer/, Resolver/ class |
| Integration | For persistence modules (schema, repository, data patch round-trips) |
| API (REST/GraphQL) | For modules declaring webapi.xml or schema.graphqls |
| JS (Jasmine) | For modules with KO components or RequireJS modules |
| MFTF | For admin UI flows (grid + form CRUD) |
Core Rules
- Discovery first. Before generating, scan the module to know exactly what's missing.
Do not overwrite existing tests unless
--overwriteis set. - Real assertions only. Every generated test must contain at least one real assertion.
Empty stubs and
markTestIncomplete()calls are forbidden. - Static-check every file. Run
php -lon every PHP test file,xmllinton every MFTF file,node --checkon every JS test before reporting done. - No source modification. This skill is purely additive. If a source class is
genuinely untestable as written, surface it as a finding and recommend
fixor a refactor task — do not refactor source. - Type-safe mocks. Use
MockObject&InterfaceNametyping on every mock property. - Source of truth. Derive output only from the target module's own code plus templates, shared
references, and baked-in Magento 2 knowledge (official Magento/Adobe docs live-fetched only when
uncertain). Do NOT read or "study" other modules under
app/code/vendor/*/Magento core to infer conventions. Seecontext/references/source-of-truth.md. - Output budget. Follow
context/references/output-budget.md— targeted reads, summary-first test/lint output, long logs to files.
Workflow
Phase 0 — Context Resolution
Invoke context. Capture vendor, runner, tools (phpunit, node, mftf).
Phase 1 — Discovery
Per module, run ${CLAUDE_SKILL_DIR}/scripts/coverage-gap.sh <module-path> to identify:
- Source classes lacking tests (Service, Plugin, Observer, Resolver, Controller, Cron, Consumer)
- Coverage gap from latest Clover/JUnit reports (if present in
var/log/) - Surfaces warranting non-unit tests (persistence → integration, rest_api/graphql → API, frontend_ui with JS → Jasmine, admin_ui → MFTF)
Produce a test plan: each missing test by type with the source it targets.
Phase 2 — Approval (APPROVAL GATE)
Present the test plan. Wait for "proceed". The user can restrict via --types=unit,api.
Phase 3 — Generate
For each missing test, use the matching template from templates/. See
references/unit-test-patterns.md, references/integration-patterns.md,
references/api-test-patterns.md, references/js-test-patterns.md,
references/mftf-patterns.md.
Generation rules per test type:
Unit
- Mock all constructor dependencies with
createMock()+MockObject&Interface. - For each public method: at least one happy-path test + one error-path test.
- For methods with significant branches: one test per branch.
Integration
- Schema test: tables exist, columns match.
- Repository test: save → get → list → delete round-trip.
- Data patch test: run patch in isolated DB; assert seeded rows.
REST API
- Per route in
webapi.xml: 200 (auth'd happy path) + 401 (unauth) + 400 (bad input).
GraphQL
- Per query/mutation: positive shape + auth fail + input error.
Jasmine
- For each KO component / RequireJS module: instantiation test + at least one public-API test.
MFTF
- For each admin grid: list-render + add-new + edit + delete flows.
Phase 4 — Verify
php -lon every PHP test file.node --checkon every JS test file.xmllint --noouton every MFTF XML file.- Run unit tests via
{ctx.runner} vendor/bin/phpunit {paths}. Fix failures. - Run integration tests if Magento install available.
- Apply the shared module-hygiene baseline (required). After generating the test PHP
files, run
${CLAUDE_PLUGIN_ROOT}/skills/context/scripts/add-license-headers.sh {ctx.magento_root}/app/code/{Vendor}/{Module} {Vendor}to stamp the standard copyright header onto every new.php— Magento test files carry it too (idempotent — it skips files that already carry it). Seecontext/references/module-hygiene.md.
Phase 5 — Report
Write to {output_root}/tests/{Vendor}_{Module}-coverage-{date}.md:
- Tests generated (count per type)
- Source classes now covered
- Source classes still uncovered (with reason)
- Updated coverage % (if measurable)
- Skill versions
Inputs
/test-generate [--types=unit,integration,api,js,mftf] [--target-coverage=80] [--docs-root=<path>] <Vendor>_<Module>| Flag | Default | Meaning |
--types | all applicable | Restrict to specific test types |
--target-coverage | 80 | Abort if generated tests can't reach target |
--missing-only | on | Generate only for classes without any test |
--overwrite | off | Re-generate even where tests exist |
--docs-root | unset | Output-root override; see "Output root" below |
Outputs
{ctx.magento_root}/app/code/{Vendor}/{Module}/Test/Unit/...
{ctx.magento_root}/app/code/{Vendor}/{Module}/Test/Integration/...
{ctx.magento_root}/app/code/{Vendor}/{Module}/Test/Api/...
{ctx.magento_root}/app/code/{Vendor}/{Module}/view/.../web/js/test/...
{ctx.magento_root}/app/code/{Vendor}/{Module}/Test/Mftf/...
{output_root}/tests/{Vendor}_{Module}-coverage-{date}.md{output_root} defaults to .docs ({ctx.docs_root}), anchored at the project root, never
under {ctx.magento_root}, app/code, or a module dir. See the Artifact location rule in
context/SKILL.md.
Output root (--docs-root)
This skill accepts --docs-root=<path> (see
context/references/artifact-layout.md). When set, write the run report (and any
report artifacts) under <path>/tests/; otherwise default to
{ctx.docs_root}/tests/. feature passes this so a feature run's
reports collect under its folder.
Reference Files
references/test-types.md— when each type is required.references/unit-test-patterns.md— per source-class-type unit test template.references/integration-patterns.md— DB fixtures, isolation, annotations.references/api-test-patterns.md— REST + GraphQL fixtures.references/js-test-patterns.md— Jasmine + RequireJS + KO patterns.references/mftf-patterns.md— MFTF section/page/test structure.references/coverage-rules.md— 80% target, exceptions, exemptions.context/references/source-of-truth.md— source-of-truth hierarchy + the no-unrelated-module-scanning rule (allowed reads, live-doc fetch protocol, report affirmation).
Templates
Templates reuse the test skeletons created in module-create/templates/
(test-controller.php, test-observer.php, test-plugin.php, test-resolver.php,
test-repository.php). Plus this skill's additions:
templates/test-service.phptemplates/test-integration-schema.phptemplates/test-integration-repository.php(legacy@magento*annotations; for Magento < 2.4.5)templates/test-integration-repository-attributes.php(attribute-first#[DataFixture]/#[DbIsolation]/#[AppArea]; preferred on Magento 2.4.5+)templates/test-integration-data-patch.phptemplates/test-api-rest.phptemplates/test-api-graphql.phptemplates/test-js-ko.jstemplates/test-mftf-listing.xmltemplates/test-mftf-form.xml
Scripts
${CLAUDE_SKILL_DIR}/scripts/coverage-gap.sh— find untested source classes and surface them by type.
Acceptance Criteria
- Every generated test contains at least one real assertion.
- Every PHP test passes
php -l; JS passesnode --check; XML passesxmllint. - Unit tests pass when run against the current module code.
- Tests are placed at the correct path mirroring source.
Related Skills
| Phase | Skill |
| 0 | context |
| (caller) | feature Phase 6, fix Phase 4, upgrade Phase 5 |
In this repository35 other files it gives its agents.
- a11y-auditSkill
- admin-formSkill
- admin-listingSkill
- auditSkill
- breeze-adaptSkill
- breeze-compatSkill
- breeze-themeSkill
- cli-commandSkill
- contextSkill
- data-migrationSkill
- debugSkill
- deploySkill
- docsSkill
- eav-attributeSkill
- extension-pointSkill
- featureSkill
- fixSkill
- frontendSkill
- graphqlSkill
- i18nSkill
- indexerSkill
- lintSkill
- marketplaceSkill
- message-queueSkill
- module-createSkill
- perf-auditSkill
- releaseSkill
- remediateSkill
- reviewSkill
- securitySkill
- system-configSkill
- triageSkill
- upgradeSkill
- webapiSkill
- widgetSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

