\r \r

Role\r

\r This skill creates or updates unit tests for WelineFramework code. It focuses on service-level behavior, model or helper logic, and deterministic regression protection that can run quickly and prove the changed logic directly.\r \r

When To Use\r

\r

• Use for PHPUnit, Pest, service tests, unit-level regression tests, and focused logic verification.\r
• Use for keywords such as unit test, PHPUnit, Pest, service test, helper test, and coverage.\r
• Use when changed logic can and should be proven without a full browser or runtime stack.\r \r

Source Material\r

\r

• AI-ENTRY.md\r
• CLAUDE.md\r
• dev/ai/skills/testing/SKILL.md\r
• dev/ai/skills/service-development/SKILL.md\r
• dev/ai/skills/code-generation-standards/SKILL.md\r
• dev/ai/skills/community-module/SKILLS-CONSOLIDATED.md\r \r

Responsibilities\r

\r

• Create targeted unit tests around changed logic.\r
• Extract logic into testable seams when direct testing is otherwise impossible.\r
• Keep assertions precise enough to protect against regression.\r
• Provide fast-running evidence that complements, rather than replaces, route or UI checks.\r \r

Workflow\r

\r

1. Read the task scope and identify the narrowest reliable unit boundary.\r
2. Confirm whether the behavior belongs in a service, helper, model, or collaborator test.\r
3. Add failing or missing test coverage that reproduces the expected behavior.\r
4. Update implementation only as needed to make the behavior testable and correct.\r
5. Run focused unit-test commands for the affected module or class.\r
6. Review for assertion quality, readability, and regression value.\r
7. Report the executed command and what behavior the test now protects.\r \r

Weline Rules\r

\r

• Prefer small, isolated, testable changes.\r
• Provide unit test evidence where relevant.\r
• Keep business logic in services instead of controllers or templates when testability matters.\r
• Do not hardcode user-facing text.\r \r

Inputs Required\r

\r

• The changed logic and its owning module.\r
• Expected behavior, edge cases, and regression risks.\r
• Existing tests or target test directory.\r
• The preferred focused test command.\r \r

Expected Output\r

\r

• New or updated unit tests that directly cover the changed logic.\r
• A focused test command and pass result.\r
• A note describing the protected regression case.\r \r

Validation\r

\r

• Run php bin/w phpunit:run --module=... or an equivalently focused test command.\r
• Confirm the test fails before the fix or clearly covers the corrected branch after the change.\r
• Confirm assertions are behavior-based rather than superficial snapshots.\r
• Confirm the test scope stays unit-level and deterministic.\r \r

Constraints\r

\r

• Do not substitute E2E-only evidence for unit-testable logic.\r
• Do not write broad brittle tests when one focused regression test is enough.\r
• Do not bury critical assertions in indirect helper chains.\r
• Do not let unit tests depend on unrelated runtime state if isolation is possible.\r \r