keisei/KeiSeiKit-1.0
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
KeiSeiKit-1.0/skills/test-gen/SKILL.md
Parfii-bot 0be354a920 KeiSeiKit-public — clean state 
Single-commit clean baseline after security scrub of niche-tells,
project codenames, internal jargon, and contributor-email leaks.

Contents:
- 100 Rust crates (_primitives/_rust/)
- 37 agent manifests (_manifests/) + generated specs (_generated/)
- 67 user-invocable skills (skills/)
- 33 hooks (hooks/)
- Composition blocks (_blocks/)
- Documentation (docs/, README.md)
- TS adapter packages (_ts_packages/)
- Assembler (_assembler/)
- Roles (_roles/)
- Templates (_templates/)
- Forgejo CI (.forgejo/)

Author: Denis Parfionovich <info@greendragon.info>

License: see LICENSE.
2026-05-01 12:09:03 +08:00

1.9 KiB
Raw Blame History

name description arguments
test-gen Use when generating tests for untested code — happy path, edge cases, error handling
name description required
target File path or function name to test true

Complements /test-matrix. /test-gen owns per-function unit tests (happy / edge / error). /test-matrix owns project-wide testing strategy (fuzz / property / load / e2e / mutation) and CI wiring. Use /test-gen for a specific function, /test-matrix at project kickoff or when coverage gaps span paradigms. See skills/test-matrix/SKILL.md.

Test Generation Workflow

Step 1: Analyze Target

  • Read the target file/function completely
  • Identify: inputs, outputs, side effects, dependencies, error paths
  • Check existing test files — don't duplicate

Step 2: Detect Framework

  • Auto-detect test framework from project:
    • Python: pytest (conftest.py, pytest.ini) or unittest
    • JS/TS: jest (jest.config), vitest (vitest.config), mocha
    • Flutter: flutter_test
    • Go: built-in testing
  • Match existing test file naming: test_*.py, *.test.ts, *_test.dart, *_test.go

Step 3: Plan Test Cases

Categories (in order of priority):

  1. Happy path — normal expected usage (2-3 cases)
  2. Edge cases — boundaries, empty inputs, max values (2-3 cases)
  3. Error handling — invalid inputs, missing data, network errors (1-2 cases)
  4. Integration — only if function interacts with external services (1 case with mock)

Step 4: Write Tests

  • Follow existing test patterns in the project
  • Use descriptive test names: test_<function>_<scenario>_<expected>
  • One assertion per test (prefer)
  • Mock external dependencies, not internal logic
  • Use fixtures/factories from existing test infrastructure

Step 5: Run & Verify

  • Run new tests — all must pass
  • Run full test suite — no regressions
  • Check coverage delta if coverage tool available

Step 6: Commit

  • test: add tests for <target>