一键导入
phpunit-unit-test-generation
Internal sub-skill. Do not auto-activate. Use only when explicitly invoked by name by another skill or agent.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Internal sub-skill. Do not auto-activate. Use only when explicitly invoked by name by another skill or agent.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use this skill when the user asks to write, create, draft, or validate an Architecture Decision Record for the Shopware core repository — phrases like "write an ADR", "create an architecture decision record", "draft a decision record", "validate this ADR", "check ADR quality", or when they mention "ADR", "architecture decision record", or "decision record" in a context that calls for capturing or auditing an architectural decision. Interactively creates ADRs (simple or multi-domain structure) with proper YAML front matter and guided content, and validates existing ADRs against front matter rules, required coverage, structure, writing style, and Shopware-specific patterns.
Use this skill when the user explicitly asks to generate, write, draft, or create a commit message, squash commit, commit title, or merge commit message for the Shopware core repository (shopware/shopware). Supports two modes — full commit messages (title + body) for branch commits, and squash merge titles (title-only) for trunk merges — the skill auto-detects which based on the current branch and PR target. Analyzes diffs, infers scope from Shopware's directory structure, and detects breaking changes. Do NOT activate during implementation work or when the user is still writing code; only when they are ready to capture a finished change. For commit messages in the ai-coding-tools marketplace repo itself, use the commit-message-generating skill instead.
Use this skill when the user asks to write, draft, create, or improve a PR description for a Shopware core repository PR — AND that PR targets a non-trunk feature branch (not trunk itself). Trigger phrases like "write a PR description", "draft the PR", "what should I put in the PR body". The skill detects the target branch and only activates for non-trunk targets; for trunk-targeting PRs, use pr-description-writing instead. Do NOT activate mid-implementation — only when the user is ready to describe finished changes. Produces a conventional-commit title and a narrative-prose description with topical subsections, leveraging the diff against the target branch and any related PRs in the chain.
Use this skill when the user asks to write, draft, create, or improve a PR description, is about to create a PR, or mentions "PR description", "pull request description", or "PR template" — AND that PR targets trunk in the Shopware core repository (shopware/shopware). The skill detects the target and only activates for trunk-targeting PRs; for PRs targeting a feature branch, use feature-branch-pr-writing instead. Do NOT activate mid-implementation — only when the user is ready to describe finished changes. Produces a conventional-commit title and a description following Shopware's 5-section template, leveraging the full branch diff against trunk and session context.
Use this skill when the user is completing features, deprecations, or breaking changes in the Shopware core repository that affect external developers, or when they ask to write release info, upgrade entries, release notes, release documentation, or changelog entries — phrases like "write a release info entry for my changes", "add an upgrade note", "what goes in RELEASE_INFO", "draft an UPGRADE.md entry". Drafts entries for RELEASE_INFO-6.*.md and UPGRADE-6.*.md based on the full branch diff against trunk, calibrated to the magnitude of change. Do NOT activate mid-implementation, for internal refactoring, non-critical bug fixes, or test-only changes — those do not get release entries.
Use this skill when the user just installed the chunkhound-integration plugin and needs to configure it, asks how to set up semantic code search or ChunkHound — phrases like "help me set up chunkhound", "configure semantic search", "set up code research" — or when ChunkHound MCP tools fail with config or connection errors. Walks through prerequisite checks (chunkhound CLI, embedding provider — VoyageAI or OpenAI), creates .chunkhound.json with the chosen provider, runs the initial index, and validates the MCP server connection.
| name | phpunit-unit-test-generation |
| version | 4.2.2 |
| description | Internal sub-skill. Do not auto-activate. Use only when explicitly invoked by name by another skill or agent. |
| user-invocable | false |
| context | fork |
| agent | test-writing:test-generator |
| allowed-tools | Read, Grep, Glob, Write, Edit, mcp__plugin_dev-tooling_php-tooling |
Generate Shopware-compliant PHPUnit unit tests that pass PHPStan and PHPUnit validation.
Write ONLY to:
tests/unit/** - Unit test filesNEVER write to:
src/** - Source code (read-only)tests/integration/** - Out of scopeBefore analyzing the source class, check if the project's phpunit.xml.dist (or phpunit.xml) excludes it from coverage. Files excluded from coverage do not need unit tests.
phpunit.xml.dist from the project root<exclude> rules inside the <coverage> or <source> section<directory suffix="X">path</directory> — excluded if file is under path AND filename ends with X<file>path/to/File.php</file> — excluded if relative path matches exactlyskip_type: coverage_excluded and reason: "Source file excluded from coverage by phpunit.xml.dist (<matched-rule>)"If phpunit.xml.dist is not found, skip this step.
Before generating any test, evaluate if the class/method requires one.
Quick check: Does the method body contain ONLY return <literal|constant|property|passthrough-new|delegation>?
skip_type: no_logic and reason describing the pattern (e.g., "Pure accessor - no logic to test")For detailed rules on what to test vs skip, see references/test-requirement-rules.md.
Read the target class to determine:
@deprecated tags, Feature::triggerDeprecationOrThrow(), Feature::silent(), Feature::callSilentIfInactive() (see references/deprecation-guards.md)Use the decision tree to select the appropriate category:
Has constructor dependencies?
├── No → Is it an Exception class?
│ ├── Yes → Category E
│ └── No → Category A (DTO)
└── Yes → Uses EntityRepository?
├── Yes → Category D (DAL)
└── No → Implements EventSubscriberInterface or FlowAction?
├── Yes → Category C (Flow/Event)
└── No → Category B (Service)
For detailed category criteria, see references/category-detection.md.
Apply these mandatory conventions when generating tests.
| Rule | Requirement |
|---|---|
| File location | tests/unit/ mirroring src/ path |
| Class attribute | #[CoversClass(TargetClass::class)] required |
| Assertions | Use static:: not $this-> |
| Base class | Extend PHPUnit\Framework\TestCase |
| Method naming | test + Action + Condition + ExpectedResult |
| Attribute order | PHPDoc -> DataProvider -> TestDox -> method |
| One behavior | NO conditionals in tests |
TestDox MUST be a predicate phrase starting with an action verb:
StaticEntityRepository, StaticSystemConfigService, GeneratorFor createStub vs createMock selection, see references/mocking-patterns.md.
For complete rules, see references/essential-rules.md.
Based on category from Phase 1:
| Category | Template |
|---|---|
| A (DTO) | templates/category-a-dto.md |
| B (Service) | templates/category-b-service.md |
| C (Flow/Event) | templates/category-c-flow.md |
| D (DAL) | templates/category-d-dal.md |
| E (Exception) | templates/category-e-exception.md |
For data provider and decoration contract patterns, see references/common-patterns.md.
{Module} - Core module (e.g., Content, Checkout, System){Submodule} - Submodule path (e.g., Product, Cart\LineItem){TargetClass} - Class name being tested{Entity} - Entity name for DAL tests{Method} - Method name being tested{Expected} - Expected outcome description{Condition} - Condition description{Exception} - Exception class nameWrite to correct location: tests/unit/{path matching src}/{ClassName}Test.php
- [ ] PHPStan passes (0 errors)
- [ ] PHPUnit passes (all tests green)
- [ ] ECS passes (code style)
{
"paths": ["tests/unit/Path/To/GeneratedTest.php"],
"error_format": "json"
}
Zero errors = pass.
Apply fixes for common errors. See references/validation-error-mapping.md.
{
"paths": ["tests/unit/Path/To/GeneratedTest.php"],
"output_format": "result-only"
}
All tests passing = success. If tests fail, re-run without output_format to get failure details for Step 4.
Apply fixes for common failures. See references/validation-error-mapping.md.
Check for violations, then apply fixes if needed.
Loop through Steps 1-5 until all validations pass.
Maximum iterations: Stop after 3 failed attempts and proceed to Phase 5.
For output format and examples, see references/output-format.md.
| Condition | Status | skip_type |
|---|---|---|
| All validations pass | SUCCESS | — |
| Test generated, validation issues remain after 3 iterations | PARTIAL | — |
| File excluded from coverage in phpunit.xml.dist | SKIPPED | coverage_excluded |
| No testable logic (per Test Requirement Rules) | SKIPPED | no_logic |
| Invalid input (not a PHP class, file not found) | FAILED | — |
For detailed patterns and techniques, consult:
Category-specific test generation templates in templates/: