agentleFS
DataDogDataDog/browser-sdk/.cursor/rules/test-driven-development.mdc

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
  1. Distinctive:

    Add edge case tests

    line 98
  2. Distinctive:

    Ensure all tests still pass

    line 99
  3. Distinctive:

    Write implementation without tests

    line 118
  4. Distinctive:

    Use real timers in tests

    line 122
  5. Distinctive:

    Test multiple behaviors in one test

    line 123
  6. Very specific:

    Use registerCleanupTask for cleanup

    line 127
  7. Distinctive:

    Test both success and failure paths

    line 129
  8. Distinctive:

    Use descriptive test names

    line 130
  9. Distinctive:

    Follow existing patterns in codebase

    line 131

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
test-driven-development.mdc
---
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.

Download now (ZIP)

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.