Master Test-Driven Development with deterministic red-green-refactor workflows, test-first feature delivery, bug reproduction through failing tests, behavior-focused assertions, and refactoring safety; use when implementing new functions, changing APIs, fixing regressions, or restructuring code under test.
Does it follow best practices?
Evaluation — 86%
↑ 1.05xAgent success when using this tile
Validation for skill structure
All test data should be visible within the test or clearly referenced. Hidden data loaded from fixtures or external files makes tests impossible to understand in isolation.
Incorrect (mystery guest from fixtures):
// fixtures/users.json - somewhere else in the codebase
// { "testUser": { "id": "u1", "role": "admin", "permissions": ["read", "write", "delete"] } }
test('admin can delete posts', async () => {
// Where does testUser come from? What role? What permissions?
const result = await deletePost('post-123', fixtures.testUser)
expect(result.success).toBe(true)
})
test('user permissions are checked', async () => {
// Reader must hunt through fixture files to understand
await expect(deletePost('post-123', fixtures.regularUser))
.rejects.toThrow('Forbidden')
})Correct (data visible in test):
test('admin can delete posts', async () => {
// All relevant information visible
const admin = createUser({ role: 'admin', permissions: ['delete'] })
const result = await deletePost('post-123', admin)
expect(result.success).toBe(true)
})
test('users without delete permission cannot delete posts', async () => {
const user = createUser({ role: 'member', permissions: ['read'] })
await expect(deletePost('post-123', user))
.rejects.toThrow('Forbidden')
})When fixtures are acceptable:
Signs of mystery guests:
Reference: Software Testing Anti-patterns - Codepipes
Install with Tessl CLI
npx tessl i pantheon-ai/test-driven-developmentevals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
references