Cline rules

1---
2description: "Guides Cline to generate comprehensive test suites alongside code — covering TDD workflows, test pyramid strategy, framework patterns, and coverage analysis."
3author: "Cline Team"
4version: "1.0"
5category: "Development"
6tags: ["testing", "tdd", "quality-assurance", "test-generation", "coverage", "ci-cd"]
7globs: ["**/*.test.*", "**/*.spec.*", "**/__tests__/**", "**/tests/**", "**/*.py", "**/*.ts", "**/*.js"]
8---
9 
10# Testing Strategy & Test Generation Protocol
11 
12## Objective
13 
14Guide Cline to proactively generate, maintain, and improve test suites as a first-class development activity — not an afterthought. Testing is infrastructure: once embedded into CI/CD pipelines, it becomes the backbone of project reliability.
15 
16---
17 
18## Core Directive
19 
20You **MUST** treat tests as mandatory deliverables. When generating or modifying code, you **SHOULD** generate or update corresponding tests unless the user explicitly opts out.
21 
22Before using `attempt_completion`, verify:
23- [ ] New/modified code has corresponding test coverage
24- [ ] Tests pass (or user has been informed of expected failures)
25- [ ] Edge cases and error paths are covered
26 
27---
28 
29## 1. Test Pyramid Strategy
30 
31Follow the test pyramid to allocate effort appropriately:
32 
33```
34        /  E2E  \          <- Few, slow, high-confidence
35       /----------\
36      / Integration \      <- Moderate, test boundaries
37     /----------------\
38    /    Unit Tests     \  <- Many, fast, isolated
39   /____________________\
40```
41 
42### Unit Tests (Foundation — 70% of tests)
43- Test individual functions, methods, and classes in isolation
44- Mock external dependencies (databases, APIs, file system)
45- **MUST** be fast (< 100ms each)
46- **MUST** be deterministic — no flaky tests
47 
48### Integration Tests (Middle — 20% of tests)
49- Test interactions between modules, services, or layers
50- Use real dependencies where practical (test databases, in-memory stores)
51- Verify API contracts, database queries, and service boundaries
52 
53### End-to-End Tests (Top — 10% of tests)
54- Test critical user journeys through the full stack
55- Use sparingly — they are slow and brittle
56- Focus on happy paths and critical business flows
57 
58---
59 
60## 2. Test-Driven Development (TDD) Workflow
61 
62When the user requests TDD or when building new features:
63 
64```
651. RED    -> Write a failing test that defines the desired behavior
662. GREEN  -> Write the minimum code to make the test pass
673. REFACTOR -> Clean up code while keeping tests green
684. REPEAT
69```
70 
71**MUST** present each step clearly to the user. Do not skip ahead.
72 
73---
74 
75## 3. Framework-Specific Patterns
76 
77### JavaScript/TypeScript (Jest / Vitest)
78```typescript
79describe('UserService', () => {
80  describe('createUser', () => {
81    it('should create a user with valid input', async () => {
82      const user = await userService.createUser({ name: 'Alice', email: 'alice@example.com' });
83      expect(user.id).toBeDefined();
84      expect(user.name).toBe('Alice');
85    });
86 
87    it('should throw on duplicate email', async () => {
88      await userService.createUser({ name: 'Alice', email: 'alice@example.com' });
89      await expect(
90        userService.createUser({ name: 'Bob', email: 'alice@example.com' })
91      ).rejects.toThrow('Email already exists');
92    });
93 
94    it('should reject invalid email format', async () => {
95      await expect(
96        userService.createUser({ name: 'Alice', email: 'not-an-email' })
97      ).rejects.toThrow('Invalid email');
98    });
99  });
100});
101```
102 
103### Python (pytest)
104```python
105import pytest
106from services.user_service import UserService
107 
108class TestUserService:
109    def test_create_user_with_valid_input(self, user_service):
110        user = user_service.create_user(name="Alice", email="alice@example.com")
111        assert user.id is not None
112        assert user.name == "Alice"
113 
114    def test_create_user_duplicate_email_raises(self, user_service):
115        user_service.create_user(name="Alice", email="alice@example.com")
116        with pytest.raises(ValueError, match="Email already exists"):
117            user_service.create_user(name="Bob", email="alice@example.com")
118 
119    def test_create_user_invalid_email_raises(self, user_service):
120        with pytest.raises(ValueError, match="Invalid email"):
121            user_service.create_user(name="Alice", email="not-an-email")
122```
123 
124### C# (xUnit)
125```csharp
126public class UserServiceTests
127{
128    [Fact]
129    public async Task CreateUser_WithValidInput_ReturnsUser()
130    {
131        var service = new UserService(mockRepo.Object);
132        var user = await service.CreateUserAsync("Alice", "alice@example.com");
133        Assert.NotNull(user.Id);
134        Assert.Equal("Alice", user.Name);
135    }
136 
137    [Fact]
138    public async Task CreateUser_DuplicateEmail_ThrowsException()
139    {
140        var service = new UserService(mockRepo.Object);
141        await service.CreateUserAsync("Alice", "alice@example.com");
142        await Assert.ThrowsAsync<DuplicateEmailException>(
143            () => service.CreateUserAsync("Bob", "alice@example.com"));
144    }
145}
146```
147 
148---
149 
150## 4. What to Test — Mandatory Coverage Areas
151 
152For every function or module, **MUST** consider:
153 
154| Category | Examples |
155|----------|----------|
156| **Happy path** | Valid inputs produce expected outputs |
157| **Edge cases** | Empty strings, zero, null, boundary values, max-length |
158| **Error handling** | Invalid inputs, network failures, timeouts, permission errors |
159| **State transitions** | Before/after mutations, side effects |
160| **Concurrency** | Race conditions, parallel execution (when applicable) |
161 
162---
163 
164## 5. Mocking & Test Doubles Strategy
165 
166- **MUST** mock external services (APIs, databases, file system) in unit tests
167- **SHOULD** use dependency injection to make code testable
168- **MUST NOT** mock the system under test — only its dependencies
169- **SHOULD** prefer fakes over mocks when the dependency is complex
170 
171```
172Stub  -> Returns canned data (simplest)
173Mock  -> Verifies interactions (use sparingly)
174Fake  -> Simplified working implementation (e.g., in-memory DB)
175Spy   -> Records calls for later assertion
176```
177 
178---
179 
180## 6. Test Quality Checklist
181 
182Before completing any testing task, verify:
183 
184- [ ] **Descriptive names**: Test names describe the scenario, not the implementation (`should_reject_expired_token` not `test1`)
185- [ ] **Arrange-Act-Assert**: Each test follows the AAA pattern clearly
186- [ ] **One assertion per concept**: Tests verify one behavior (multiple `expect` calls are fine if they verify one logical outcome)
187- [ ] **No test interdependence**: Tests can run in any order
188- [ ] **No hardcoded sleep/delays**: Use polling, events, or test clocks
189- [ ] **Meaningful assertions**: Assert specific values, not just "no error thrown"
190 
191---
192 
193## 7. Coverage Analysis
194 
195When asked about coverage or when completing a testing task:
196 
197- **SHOULD** suggest running coverage tools (`jest --coverage`, `pytest --cov`, `dotnet test --collect:"XPlat Code Coverage"`)
198- **Target**: 80%+ line coverage for business logic, 90%+ for critical paths
199- **MUST NOT** chase 100% — focus on meaningful coverage, not vanity metrics
200- Uncovered code **SHOULD** be flagged with rationale (e.g., "UI rendering — covered by E2E tests")
201 
202---
203 
204## 8. CI/CD Integration Guidance
205 
206When setting up or advising on CI/CD:
207 
208- Tests **MUST** run on every PR/push
209- Fast unit tests run first; slow integration/E2E tests run after
210- Failed tests **MUST** block merge
211- Coverage reports **SHOULD** be posted as PR comments
212- Flaky tests **MUST** be quarantined and fixed, not ignored
213 
214<!-- 
215Enterprise Considerations:
216- Team-wide configurable coverage thresholds enforced across all repositories
217- Test health dashboards showing pass rates, flakiness trends, and coverage gaps
218- Shared test fixture and pattern libraries distributed across teams
219- Automated test quality scoring and team benchmark comparisons
220-->
221