Tdd mastery
Skill timdevai/proteus/skills/community/from-rohitg00/tdd-mastery
Test-driven development workflow with Red-Green-Refactor cycle across languagesFrom its SKILL.md
npx -y skills add timdevai/proteus --skill tdd-masteryAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
4.4 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it
TDD Mastery
Core Cycle: Red-Green-Refactor
- Red - Write a failing test that defines the desired behavior
- Green - Write the minimum code to make the test pass
- Refactor - Clean up while keeping tests green
Never write production code without a failing test first. Each cycle should take 2-10 minutes.
Test Structure
Use the Arrange-Act-Assert pattern consistently:
Arrange: Set up test data and dependencies
Act: Execute the behavior under test
Assert: Verify the expected outcome
Name tests as test_<unit>_<scenario>_<expected_result> or it("should <behavior> when <condition>").
Jest / Vitest Patterns
describe("OrderService", () => {
it("should apply discount when order exceeds threshold", () => {
const order = createOrder({ items: [{ price: 150, qty: 1 }] });
const result = applyDiscount(order, { threshold: 100, percent: 10 });
expect(result.total).toBe(135);
});
it("should throw when applying discount to empty order", () => {
const order = createOrder({ items: [] });
expect(() => applyDiscount(order, defaultDiscount)).toThrow(EmptyOrderError);
});
});
Use vi.fn() / jest.fn() for mocks. Prefer dependency injection over module mocking. Use beforeEach for shared setup, never share mutable state between tests.
pytest Patterns
@pytest.fixture
def db_session():
session = create_test_session()
yield session
session.rollback()
def test_create_user_stores_hashed_password(db_session):
user = UserService(db_session).create(email="[email protected]", password="secret")
assert user.password_hash != "secret"
assert verify_password("secret", user.password_hash)
@pytest.mark.parametrize("input,expected", [
("", False),
("short", False),
("ValidPass1!", True),
])
def test_password_validation(input, expected):
assert validate_password(input) == expected
Use pytest.raises for exceptions. Use conftest.py for shared fixtures. Mark slow tests with @pytest.mark.slow.
Go Testing Patterns
func TestParseConfig(t *testing.T) {
tests := []struct {
name string
input string
want Config
wantErr bool
}{
{"valid yaml", "port: 8080", Config{Port: 8080}, false},
{"empty input", "", Config{}, true},
{"invalid port", "port: -1", Config{}, true},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
got, err := ParseConfig([]byte(tt.input))
if (err != nil) != tt.wantErr {
t.Errorf("ParseConfig() error = %v, wantErr %v", err, tt.wantErr)
return
}
if !tt.wantErr && got != tt.want {
t.Errorf("ParseConfig() = %v, want %v", got, tt.want)
}
})
}
}
Use table-driven tests by default. Use t.Helper() in test utility functions. Use testify/assert only if the team already uses it.
Test Levels
| Level | Scope | Speed | Dependencies |
|---|---|---|---|
| Unit | Single function/class | <100ms | None (mock all) |
| Integration | Module boundaries | <5s | Real DB, real FS |
| E2E | Full user flow | <30s | Full stack |
Ratio target: 70% unit, 20% integration, 10% e2e.
Coverage Rules
- Enforce 80% line coverage minimum in CI
- Track branch coverage, not just line coverage
- Exclude generated code, type definitions, and config files
- Never write tests just to hit coverage numbers; test behavior
# Jest/Vitest
vitest run --coverage --coverage.thresholds.lines=80 --coverage.thresholds.branches=75
# pytest
pytest --cov=src --cov-fail-under=80 --cov-branch
# Go
go test -coverprofile=cover.out -coverpkg=./... ./...
go tool cover -func=cover.out
Mocking Guidelines
- Mock at boundaries: HTTP clients, databases, file systems, clocks
- Never mock the unit under test
- Prefer fakes (in-memory implementations) over mocks for repositories
- Assert on behavior, not on mock call counts
- Use
t.Cleanup/afterEachto reset shared mocks
Anti-Patterns to Avoid
- Testing implementation details instead of behavior
- Tests that pass when code is deleted (tautological tests)
- Shared mutable state between test cases
- Ignoring flaky tests instead of fixing them
- Testing private methods directly
- Giant test setup that obscures intent
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 3 of the 12 instructions most tdd skills give in ~1.1k tokens
Counted across 594 of the 695 authors here whose files we hold, read 2026-09-06
- Write minimal code to pass the testhere, and in 356 of 594, across 332 files
- Write a failing test before writing production codehere, and in 240 of 594, across 221 files
- Refactor code only after tests passin 184 of 594, across 169 files
- Refactor code while keeping tests greenhere, and in 140 of 594, across 133 files
- Verify the test fails for the expected reasonin 133 of 594, across 121 files
- Run tests after each refactor stepin 108 of 594, across 102 files
- Use real code instead of mocks whenever possiblein 97 of 594, across 85 files
- Reproduce bugs with a failing test before fixingin 90 of 594, across 81 files
- Write tests before implementing codein 88 of 594, across 70 files
- Verify the test passes after writing codein 71 of 594, across 61 files
- Write one test for one behaviorin 71 of 594, across 63 files
- Run the full test suitein 63 of 594, across 56 files
Said here and by no other author read
- Use beforeEach for shared setup
- Use table-driven tests for Go
- Prefer fakes over mocks for repositories
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.