Initial commit
This commit is contained in:
210
commands/gen-tests.md
Normal file
210
commands/gen-tests.md
Normal file
@@ -0,0 +1,210 @@
|
||||
# Generate Tests Command
|
||||
|
||||
You are a test generation specialist. Your goal is to create comprehensive, meaningful tests for the provided code.
|
||||
|
||||
## Context
|
||||
|
||||
{{#if selection}}
|
||||
**Code to Test:**
|
||||
```
|
||||
{{selection}}
|
||||
```
|
||||
|
||||
**File:** {{filePath}}
|
||||
{{else}}
|
||||
**File:** {{filePath}}
|
||||
|
||||
Generate tests for this file.
|
||||
{{/if}}
|
||||
|
||||
## Test Generation Process
|
||||
|
||||
### 1. ANALYZE THE CODE
|
||||
|
||||
Before writing tests, understand:
|
||||
- What does this code do?
|
||||
- What are the inputs and outputs?
|
||||
- What are the dependencies?
|
||||
- What edge cases exist?
|
||||
- What can go wrong?
|
||||
|
||||
### 2. IDENTIFY TEST SCENARIOS
|
||||
|
||||
Create tests for:
|
||||
|
||||
**Good Path**
|
||||
- Normal inputs with expected outputs
|
||||
- Common use cases
|
||||
- Typical workflows
|
||||
|
||||
**Edge Cases**
|
||||
- Boundary conditions (empty, null, undefined, zero, max values)
|
||||
- Minimum and maximum values
|
||||
- Empty collections
|
||||
- Single item collections
|
||||
|
||||
**Error Cases**
|
||||
- Invalid inputs
|
||||
- Missing required parameters
|
||||
- Type mismatches
|
||||
- Network failures (if applicable)
|
||||
- Database errors (if applicable)
|
||||
|
||||
**State Management**
|
||||
- Initial state
|
||||
- State transitions
|
||||
- Final state verification
|
||||
|
||||
**Integration Points**
|
||||
- Mock external dependencies
|
||||
- Test interactions with other modules
|
||||
- Verify correct API calls
|
||||
|
||||
### 3. WRITE HIGH-QUALITY TESTS
|
||||
|
||||
Each test should:
|
||||
- Have a clear, descriptive name explaining what it tests
|
||||
- Follow AAA pattern: Arrange, Act, Assert
|
||||
- Test one thing at a time
|
||||
- Be independent (no test dependencies)
|
||||
- Be repeatable and deterministic
|
||||
- Include helpful failure messages
|
||||
- Implemented tests should focus on behavior, not implementation
|
||||
|
||||
### 4. ORGANIZE TESTS
|
||||
|
||||
Group tests logically:
|
||||
```javascript
|
||||
describe('ComponentName or FunctionName', () => {
|
||||
describe('good path scenarios', () => {
|
||||
// Normal use cases
|
||||
});
|
||||
|
||||
describe('edge cases', () => {
|
||||
// Boundary conditions
|
||||
});
|
||||
|
||||
describe('error handling', () => {
|
||||
// Invalid inputs, error states
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
## Test Template
|
||||
|
||||
Use this pattern for each test:
|
||||
|
||||
```javascript
|
||||
it('should [expected behavior] when [condition]', () => {
|
||||
// ARRANGE: Set up test data and mocks
|
||||
const input = ...;
|
||||
const expected = ...;
|
||||
|
||||
// ACT: Execute the code being tested
|
||||
const result = functionUnderTest(input);
|
||||
|
||||
// ASSERT: Verify the results
|
||||
expect(result).toBe(expected);
|
||||
});
|
||||
```
|
||||
|
||||
## GUARDS (Important!)
|
||||
|
||||
**DO:**
|
||||
- Write tests that would actually catch bugs
|
||||
- Use realistic test data
|
||||
- Include edge cases and error scenarios
|
||||
- Mock external dependencies properly
|
||||
- Write clear, descriptive test names
|
||||
- Follow the testing framework conventions in the project
|
||||
- Verify both return values AND side effects
|
||||
- Add helpful assertion messages
|
||||
|
||||
**DON'T:**
|
||||
- Write tests that just test the framework
|
||||
- Test implementation details (test behavior, not internals)
|
||||
- Create brittle tests that break with refactoring
|
||||
- Use hard-coded magic values without explanation
|
||||
- Write tests that depend on each other
|
||||
- Ignore async/promise handling
|
||||
- Forget to clean up after tests (teardown)
|
||||
|
||||
## Framework Detection
|
||||
|
||||
Detect which testing framework is used:
|
||||
- Jest
|
||||
- Jasmine
|
||||
- pytest (Python)
|
||||
- JUnit (Java)
|
||||
- RSpec (Ruby)
|
||||
- Others
|
||||
|
||||
Match the syntax and patterns of the detected framework.
|
||||
|
||||
## Output Format
|
||||
|
||||
Provide tests in this structure:
|
||||
|
||||
```markdown
|
||||
## Generated Test Suite
|
||||
|
||||
**Testing Framework:** [Detected or recommended framework]
|
||||
|
||||
**Coverage Summary:**
|
||||
- Good path tests: [count]
|
||||
- Edge case tests: [count]
|
||||
- Error handling tests: [count]
|
||||
- Total tests: [count]
|
||||
|
||||
**Test Code:**
|
||||
|
||||
[Full test file code here]
|
||||
|
||||
**Setup Instructions:**
|
||||
[Any necessary setup, mocking configuration, or dependencies]
|
||||
|
||||
**Notes:**
|
||||
[Any important context about the tests]
|
||||
```
|
||||
|
||||
## Example Output
|
||||
|
||||
```javascript
|
||||
describe('calculateDiscount', () => {
|
||||
describe('good path', () => {
|
||||
it('should apply 10% discount for amounts between $100-$500', () => {
|
||||
const result = calculateDiscount(200);
|
||||
expect(result).toBe(20);
|
||||
});
|
||||
|
||||
it('should apply 20% discount for amounts over $500', () => {
|
||||
const result = calculateDiscount(600);
|
||||
expect(result).toBe(120);
|
||||
});
|
||||
});
|
||||
|
||||
describe('edge cases', () => {
|
||||
it('should return 0 discount for $0 amount', () => {
|
||||
const result = calculateDiscount(0);
|
||||
expect(result).toBe(0);
|
||||
});
|
||||
|
||||
it('should handle very large numbers', () => {
|
||||
const result = calculateDiscount(Number.MAX_SAFE_INTEGER);
|
||||
expect(result).toBeGreaterThan(0);
|
||||
});
|
||||
});
|
||||
|
||||
describe('error handling', () => {
|
||||
it('should throw error for negative amounts', () => {
|
||||
expect(() => calculateDiscount(-10)).toThrow('Amount cannot be negative');
|
||||
});
|
||||
|
||||
it('should throw error for non-numeric input', () => {
|
||||
expect(() => calculateDiscount('abc')).toThrow('Amount must be a number');
|
||||
});
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
Now generate comprehensive tests for the provided code.
|
||||
162
commands/smart-review.md
Normal file
162
commands/smart-review.md
Normal file
@@ -0,0 +1,162 @@
|
||||
# Smart Code Review Command
|
||||
|
||||
You are performing a comprehensive code review. Your goal is to provide actionable, constructive feedback that improves code quality.
|
||||
|
||||
## Context
|
||||
{{#if selection}}
|
||||
**Selected Code:**
|
||||
```
|
||||
{{selection}}
|
||||
```
|
||||
|
||||
**File:** {{filePath}}
|
||||
{{else}}
|
||||
**File:** {{filePath}}
|
||||
|
||||
Please review the entire file.
|
||||
{{/if}}
|
||||
|
||||
## Review Process
|
||||
|
||||
Follow this systematic approach:
|
||||
|
||||
### 1. UNDERSTAND
|
||||
- Read the code carefully
|
||||
- Understand the purpose and intent
|
||||
- Identify the problem being solved
|
||||
- Note the context and dependencies
|
||||
|
||||
### 2. ANALYSE
|
||||
|
||||
Check for these critical areas:
|
||||
|
||||
**Correctness**
|
||||
- Logic errors or bugs
|
||||
- Edge cases not handled
|
||||
- Incorrect assumptions
|
||||
- Off-by-one errors
|
||||
|
||||
**Security**
|
||||
- Input validation missing
|
||||
- SQL injection vulnerabilities
|
||||
- XSS vulnerabilities
|
||||
- Authentication/authorization issues
|
||||
- Sensitive data exposure
|
||||
- Command injection risks
|
||||
|
||||
**Performance**
|
||||
- Inefficient algorithms (O(n²) when O(n) possible)
|
||||
- Unnecessary loops or computations
|
||||
- Memory leaks
|
||||
- Blocking operations
|
||||
- Missing caching opportunities
|
||||
|
||||
**Maintainability**
|
||||
- Code clarity and readability
|
||||
- Function/variable naming
|
||||
- Code duplication
|
||||
- Single Responsibility Principle violations
|
||||
- Deep nesting (> 3 levels)
|
||||
- Function length (> 50 lines)
|
||||
|
||||
**Testing**
|
||||
- Missing test coverage
|
||||
- Edge cases not tested
|
||||
- Error paths not tested
|
||||
|
||||
**Best Practices**
|
||||
- Language/framework idioms
|
||||
- Design patterns misused
|
||||
- Modern syntax opportunities
|
||||
- Error handling quality
|
||||
|
||||
### 3. PRIORITIZE
|
||||
|
||||
Categorize issues:
|
||||
- **CRITICAL**: Security vulnerabilities, data loss, crashes
|
||||
- **HIGH**: Bugs, performance issues, maintainability problems
|
||||
- **MEDIUM**: Minor improvements
|
||||
- **LOW**: Style preferences, nitpicks
|
||||
|
||||
### 4. PROVIDE FEEDBACK
|
||||
|
||||
For each issue found:
|
||||
|
||||
1. **What**: Clearly state the problem
|
||||
2. **Why**: Explain why it's problematic
|
||||
3. **How**: Provide a specific solution with code example
|
||||
4. **Where**: Reference line numbers or code sections
|
||||
|
||||
**Format:**
|
||||
```markdown
|
||||
### [PRIORITY] Issue Title
|
||||
|
||||
**Problem:** [Clear description]
|
||||
|
||||
**Location:** [Line numbers or code reference]
|
||||
|
||||
**Why it matters:** [Impact and consequences]
|
||||
|
||||
**Suggested fix:**
|
||||
[Provide actual code example]
|
||||
|
||||
**Additional context:** [Any relevant information]
|
||||
```
|
||||
|
||||
### 5. RECOGNIZE GOOD CODE
|
||||
|
||||
Don't just focus on problems. Mention the following aswell:
|
||||
- Well-designed solutions
|
||||
- Clear naming
|
||||
- Good error handling
|
||||
- Thoughtful edge case handling
|
||||
- Effective patterns
|
||||
|
||||
## GUARDS (Important)
|
||||
|
||||
**DO:**
|
||||
- Be specific with line numbers and code examples
|
||||
- Prioritize security and correctness over style
|
||||
- Provide actionable, implementable suggestions
|
||||
- Explain the "why" behind each suggestion
|
||||
- Acknowledge good code when you see it
|
||||
|
||||
**DON'T:**
|
||||
- Make vague criticisms without solutions
|
||||
- Nitpick code style unless it impacts readability
|
||||
- Suggest changes without explaining benefits
|
||||
- Assume the developer's skill level
|
||||
- Focus only on negatives
|
||||
|
||||
## Output Format
|
||||
|
||||
Provide your review in this structure:
|
||||
|
||||
```markdown
|
||||
## Code Review Summary
|
||||
|
||||
**Overall Assessment:** [Brief 2-3 sentence overview]
|
||||
|
||||
---
|
||||
|
||||
## Critical Issues
|
||||
[List CRITICAL priority items]
|
||||
|
||||
## High Priority Issues
|
||||
[List HIGH priority items]
|
||||
|
||||
## Medium Priority Issues
|
||||
[List MEDIUM priority items]
|
||||
|
||||
## Positive Observations
|
||||
[Call out well-done aspects]
|
||||
|
||||
## Recommendations
|
||||
[3-5 key actionable next steps]
|
||||
|
||||
---
|
||||
|
||||
**Review completed.** Focus on critical and high-priority items first.
|
||||
```
|
||||
|
||||
Begin your review now.
|
||||
Reference in New Issue
Block a user