browser-sdk / rules
Cursor rule400 starsChanged 9 months agoApache-2.0View on GitHub
Standards for Test-Driven Development in the Browser SDK project
We split this test-driven-development.mdc into the rules it gives an agent
9 rules. About 0 are common, 8 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 98
Add edge case tests
- Distinctive: line 99
Ensure all tests still pass
- Distinctive: line 118
Write implementation without tests
- Distinctive: line 122
Use real timers in tests
- Distinctive: line 123
Test multiple behaviors in one test
- Very specific: line 127
Use registerCleanupTask for cleanup
- Distinctive: line 129
Test both success and failure paths
- Distinctive: line 130
Use descriptive test names
- Distinctive: line 131
Follow existing patterns in codebase
≈ “Common” is an estimate: at least 1 in 5 of the 6,350 Cursor rule files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
---
description: Standards for Test-Driven Development in the Browser SDK project
globs:
tags:
- jasmine
- karma
alwaysApply: true
---
# Test-Driven Development (TDD) Rule
## 1. RED-GREEN-REFACTOR Cycle
**ALWAYS follow this sequence:**
1. 🔴 **RED**: Write failing test first
2. 🟢 **GREEN**: Write minimal code to make test pass
3. 🔵 **REFACTOR**: Improve code while keeping tests green
## 2. Spec First, Code Second
**Before writing ANY implementation:**
```bash
# Check for existing spec file
ls packages/some-package/src/path/to/feature.spec.ts
# If missing, create spec file first
touch packages/some-package/src/path/to/feature.spec.ts
```
**Spec file must exist BEFORE implementation file**
## 3. Spec Structure (Jasmine/Karma)
```typescript
describe('FeatureName', () => {
// Setup variables
let feature: FeatureType
let mockDependency: MockType
beforeEach(() => {
// Setup for each test
mockDependency = jasmine.createSpy()
feature = new FeatureName(mockDependency)
// Use registerCleanupTask for cleanup
registerCleanupTask(() => {
feature.dispose()
})
})
describe('when condition', () => {
it('should behave correctly', () => {
// Arrange
const input = 'test-input'
// Act
const result = feature.process(input)
// Assert
expect(result).toBe(expectedOutput)
expect(mockDependency).toHaveBeenCalledWith(input)
})
it('should handle edge cases', () => {
// Test edge cases, errors, boundaries
})
})
})
```
## 4. Implementation Process
**Step-by-step workflow:**
1. **Analyze Requirements**
- Understand the feature/bug
- Identify acceptance criteria
- Consider edge cases
2. **Create/Review Spec**
3. **Run Tests (Should Fail)**
```bash
yarn test:unit
# Verify test fails for the right reason
```
4. **Implement Minimal Code**
5. **Run Tests (Should Pass)**
```bash
yarn test:unit
# Verify test passes
```
6. **Refactor & Add More Tests**
- Improve implementation
- Add edge case tests
- Ensure all tests still pass
## 5. Browser SDK Specific Patterns
**Use established test utilities:**
[unit-test.mdc](mdc:.cursor/rules/unit-test.mdc)
**Follow co-location pattern:**
```
src/
├── domain/
│ ├── feature.ts ← Implementation
│ ├── feature.spec.ts ← Tests (co-located)
│ └── anotherFeature.ts
```
## 8. Error Prevention Rules
**❌ NEVER do this:**
- Write implementation without tests
- Skip edge case testing
- Leave failing tests
- Forget cleanup tasks
- Use real timers in tests
- Test multiple behaviors in one test
**✅ ALWAYS do this:**
- Write test first
- Use `registerCleanupTask` for cleanup
- Mock external dependencies
- Test both success and failure paths
- Use descriptive test names
- Follow existing patterns in codebase
Remember: **Tests are documentation**. Write them as if explaining the feature to a new team member.
Where files are headingNew Cursor rule files have more rules about planning and tracking tasks, and fewer about code style.
Of the Cursor rule files we read, the 3,978 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository8 other files it gives its agents.
- AGENTS.mdAGENTS.md
- scripts/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- scripts/CLAUDE.mdCLAUDE.md
- .cursor/rules/unit-test-best-practices.mdcCursor rule
- manual-testingSkill
- running-testsSkill
- writing-commits-and-prsSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

