Tests Kit

Test case guardian and insertion tool for the Synnovator platform's business scenarios defined in specs/testcases/.

Mode 1: Guard — Verify Existing Test Cases

Run this workflow before committing any change to synnovator skill scripts, data model docs, or spec files.

Guard Workflow

1. Run validation script to check structural integrity:

   bashCopy

   uv run python .claude/skills/tests-kit/scripts/check_testcases.py
   

   This checks: TC ID format, uniqueness across files, file structure, and format conventions.

2. Identify affected test cases based on the change:

   • Read references/testcase-index.md to find TC IDs related to the changed module
   • Map changes to affected TC prefixes:
     • content.py / endpoint scripts → TC-USER, TC-CAT, TC-RULE, TC-GRP, TC-POST, TC-RES, TC-IACT
     • relations.py → TC-REL-*
     • cascade.py → TC-DEL-*
     • cache.py → TC-IACT-003, TC-IACT-013, TC-IACT-021 (counter tests)
     • rules.py → TC-RULE-100+, TC-ENGINE-*, TC-ENTRY-*, TC-CLOSE-*
     • docs/data-types.md → All content type TCs
     • docs/relationships.md → TC-REL-*, TC-FRIEND-*, TC-STAGE-*, TC-TRACK-*, TC-PREREQ-*
     • docs/crud-operations.md → TC-PERM-*, all CRUD TCs
     • docs/rule-engine.md → TC-ENGINE-*, TC-ENTRY-*, TC-CLOSE-*

3. Read the affected test case files in specs/testcases/ and verify each scenario still holds given the proposed change.

4. Report conflicts — If any test case would be broken:

   • List each broken TC ID with explanation
   • Propose how to resolve (fix implementation to preserve TC, or update TC with user approval)

Mode 2: Insert — Add New Test Cases

Run this workflow when the user wants to add new test scenarios.

Insert Workflow

1. Understand the scenario the user wants to test. Ask for:

   • What business behavior should be covered?
   • Which content types / relations / rules are involved?

2. Check existing coverage — Read references/testcase-index.md and search for overlapping or similar TCs. If the scenario is already covered, inform the user.

3. Try to fit within existing specs — Before proposing any spec changes:

   • Read relevant files in docs/ and specs/ to understand current data model and constraints
   • Attempt to express the test using existing content types, relations, and rule engine features
   • Consider: Can the test be decomposed into multiple steps using existing primitives?
   • Consider: Can an existing data type (e.g., interaction, post:post relation) serve as an indirect wrapper?
   • If the scenario can be expressed without spec changes, proceed to step 5

4. If spec changes are needed — Present to the user:

   • Which spec file(s) need modification
   • What the minimum change would be
   • Impact analysis: which existing TCs might be affected
   • Wait for user approval before proceeding

5. Determine placement — Read references/testcase-format.md for conventions:

   • Identify the correct file (by module) or decide if a new file is needed
   • Pick the next available TC ID number within the appropriate range
   • Place positive cases in 001-099 (or 100-199 for feature-specific), negative in 900-999

6. Write the test case following format conventions:

   • Chinese language
   • **TC-PREFIX-NNN：Title** format
   • Scenario + expected result only, no test method
   • Single paragraph unless multi-effect cascade

7. Run validation after insertion:

   bashCopy

   uv run python .claude/skills/tests-kit/scripts/check_testcases.py
   

Resources

scripts/

• check_testcases.py — Validate all test case files for format consistency, TC ID uniqueness, and structural correctness. Run with uv run python .claude/skills/tests-kit/scripts/check_testcases.py.

references/

• testcase-index.md — Complete catalog of all 267 test cases with TC IDs, descriptions, and file locations. Read this to find related test cases or check coverage.
• testcase-format.md — File naming, TC ID conventions, number ranges, writing rules, and structural template. Read this before writing new test cases.