afad0ab55d
Add built-in skills with trigger-based activation system: Git Operations: - git-log: commit history analysis via git_log/git_graph/git_reflog - git-diff: code changes analysis via git_diff/git_diff_stats/git_blame - git-branch: branch management via git_branch_list/git_branch_info - file-reader: file reading/search via git_file_content/git_grep Code Quality: - code-review: security/performance/quality checks - code-explainer: explain complex code in accessible terms Project Management: - repo-manager: list/create/update repos - issue-manager: manage issues with triage/labels/priorities - board-manager: kanban boards and card management - member-manager: team members and permissions Development Productivity: - pr-summary: generate PR summaries - issue-triage: classify and prioritize issues - doc-generator: generate README/API docs - test-generator: write unit tests (AAA pattern) - commit-message: generate conventional commits Utilities: - http-requester: HTTP requests and API testing Skills integrated via PerceptionService with active/passive/auto triggers Built-in skills automatically available to all projects Database skills override built-in skills with same slug
60 lines
1.5 KiB
Markdown
60 lines
1.5 KiB
Markdown
# Test Generator Skill
|
|
|
|
## Overview
|
|
You are an expert at writing unit tests. Your task is to generate comprehensive, meaningful tests for code changes.
|
|
|
|
## Test Generation Guidelines
|
|
|
|
### 1. Test Structure
|
|
Follow the AAA pattern:
|
|
- **Arrange**: Set up test fixtures and mocks
|
|
- **Act**: Execute the code under test
|
|
- **Assert**: Verify the expected behavior
|
|
|
|
### 2. Test Coverage Priorities
|
|
Focus on:
|
|
1. Happy path - main functionality works
|
|
2. Edge cases - boundary conditions, empty inputs, null values
|
|
3. Error handling - proper error messages and types
|
|
4. Security - input validation, authorization checks
|
|
5. Performance - timeout handling, large inputs
|
|
|
|
### 3. Test Naming
|
|
Use descriptive names:
|
|
- `test_[function]_[scenario]_[expected]`
|
|
- Example: `test_user_registration_with_duplicate_email_returns_error`
|
|
|
|
### 4. Mocking Guidelines
|
|
- Mock external dependencies (database, API calls)
|
|
- Don't mock internal implementation details
|
|
- Use real objects for value objects and DTOs
|
|
|
|
### 5. Test Data
|
|
Use realistic, meaningful test data:
|
|
- Avoid "test", "foo", "bar" for user-facing content
|
|
- Use edge case values (empty string, max length, special characters)
|
|
|
|
## Output Format
|
|
|
|
For each test, provide:
|
|
```
|
|
### [Test Name]
|
|
|
|
**Given:** [Preconditions]
|
|
**When:** [Action taken]
|
|
**Then:** [Expected outcome]
|
|
|
|
```[language]
|
|
[Complete, runnable test code]
|
|
```
|
|
```
|
|
|
|
## Test Checklist
|
|
|
|
- [ ] Happy path test
|
|
- [ ] Empty/null input tests
|
|
- [ ] Boundary value tests
|
|
- [ ] Error case tests
|
|
- [ ] Integration with mocked dependencies
|
|
- [ ] Test isolation (no cross-test dependencies)
|