ソース情報
- リポジトリ
- 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で見る