generate-tests

Generate Tests Skill

You will analyze code and generate high-quality unit tests for a given target.

Target to test: $ARGUMENTS

Quality Standards

• Take your time to analyze the code thoroughly before generating test cases.
• Quality is more important than speed — read all relevant source files and rules carefully.
• Do not skip any step in the workflow below. Every step exists for a reason.
• Do not take shortcuts with test data — read the actual classes to use correct constructors and fields.

---

Instructions

Step 1: Read Rules and Analyze Context

1. Read the relevant rules from ./rules/tests/ based on code type (see Rules Reference below)
2. Read the target source file/class/method
3. Read dependencies: Follow imports to read DTOs, entities, enums, custom exceptions, and other types referenced by the target (as specified in code-context-analysis rule)
4. Check for existing tests: Search for {ClassName}Test or {ClassName}Tests in the test directory (as specified in existing-test-awareness rule)
   • If found, read fully — you will add missing tests to it, not create a new file
   • If not found, scan 2-3 neighboring test classes to learn project conventions

Step 2: Establish the Test Case List

If a test case list for this target is already present — generate-test-cases ran first, whether the user invoked it or the agent did — that list is the plan. Generate from it. Do not re-analyze the target from scratch; where your reading of the code differs, name the cases you add or drop and why, so the change to the plan is visible.

If there is no such list, produce one here before writing any test code:

1. Analyze ALL code branches, including:
   • Success paths
   • Error/exception paths
   • Validation logic
   • Private/protected methods called by the target
   • Security annotations (if present)
2. Apply the INCLUDE/EXCLUDE rules strictly
3. Output the list in the format below

Either way, continue straight to Step 3. The list is printed so the user can audit the plan against the generated tests afterwards; the run stays unattended end to end.