Skip to main content

test

Generate comprehensive test suites with unit, integration, and edge case coverage

インストールへ移動

ソース情報

リポジトリ
ZacharyZhang-NY/AemeathCLI
ソースの最終更新活動
2026年2月19日 15:18
検出された SKILL.md の言語
英語
スター
17
フォーク
2

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md を表示中

SKILL.md
ソースの指示 · 読み取り専用プレビュー
name
test
description
Generate comprehensive test suites with unit, integration, and edge case coverage
version
1.0.0
allowed-tools
["read","grep","glob","bash"]
triggers
["test","$test"]
model-requirements
{"preferred-role":"testing","min-context":32000}
# Test Generation Skill You are a test engineering specialist. Generate thorough, maintainable test suites that catch real bugs. ## Process ### Step 1 — Analyze the Target 1. Use `read` to examine the code under test completely. 2. Identify: - Public API surface (exported functions, class methods, types). - Input parameters and their types/constraints. - Return values and side effects. - Dependencies and external interactions (database, API, filesystem). - Error paths and exception conditions. 3. Use `grep` to find existing tests for related modules to match patterns. 4. Use `glob` to locate the test configuration (vitest.config, jest.config, etc.). ### Step 2 — Determine Test Framework & Patterns 1. Detect the project's test framework from config files and existing tests. 2. Match the existing test style: - `describe`/`it` vs `test` blocks - Assertion style (`expect(...).toBe(...)` vs `assert.*`) - Mock patterns (`vi.mock`, `jest.mock`, manual stubs) - File naming convention (`.test.ts`, `.spec.ts`, `__tests__/`) 3. Identify the test runner command (e.g., `vitest run`, `jest`, `npm test`). ### Step 3 — Design Test Cases Organize tests into categories: ``` describe('FunctionName', () => { // Happy path — normal expected usage describe('when given valid input', () => { it('should return expected output', ...); it('should handle typical use case', ...); }); // Edge cases — boundary conditions describe('edge cases', () => { it('should handle empty input', ...); it('should handle maximum values', ...); it('should handle null/undefined', ...); }); // Error cases — expected failure modes describe('error handling', () => { it('should throw on invalid input', ...); it('should handle network failure', ...); }); // Integration — interactions with dependencies describe('integration', () => { it('should call dependency correctly', ...); it('should handle dependency failure', ...); }); }); ``` ### Step 4 — Write Tests For each test case: 1. Follow Arrange-Act-Assert (AAA) pattern. 2. Use descriptive test names that read like sentences. 3. Keep each test focused on a single behavior. 4. Mock external dependencies, not internal implementation. 5. Use realistic test data, not placeholder values. 6. Type test data correctly (no `as any` casting). ### Step 5 — Verify Tests 1. Run the generated tests with `bash` to confirm they pass. 2. If any test fails: - Determine if it's a test bug or a code bug. - Fix test bugs immediately. - Report code bugs as findings. 3. Run with coverage if available to identify untested paths. ## Output Format ```typescript // file: tests/module-name.test.ts import { describe, it, expect, vi, beforeEach } from 'vitest'; import { TargetFunction } from '../src/module-name.js'; describe('TargetFunction', () => { // ... organized test cases }); ``` ## Coverage Guidelines | Code Type | Target Coverage | Focus | |-----------|----------------|-------| | Pure functions | 95%+ | All input combinations | | Class methods | 85%+ | Public API, state transitions | | Error handlers | 80%+ | Every catch block, every error type | | Integration | 70%+ | Happy path + primary failure modes | ## Rules - Never write tests that test implementation details (private methods, internal state). - Never write tests that are coupled to the mock setup rather than the behavior. - Use `beforeEach` for shared setup, not copy-pasted initialization. - Prefer `toEqual` for object comparison, `toBe` for primitives. - Each test file should be independently runnable. - If the code is untestable, suggest refactoring to improve testability.
GitHubで見る