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
Each test should verify one logical concept. When a test fails, you should know exactly what's broken without reading the test body.
Incorrect (multiple unrelated assertions):
test('user service', async () => {
const user = await userService.create({ name: 'Alice', email: 'alice@test.com' })
expect(user.id).toBeDefined()
expect(user.name).toBe('Alice')
expect(user.email).toBe('alice@test.com')
expect(user.createdAt).toBeInstanceOf(Date)
const fetched = await userService.getById(user.id)
expect(fetched).toEqual(user)
await userService.delete(user.id)
expect(await userService.getById(user.id)).toBeNull()
})
// If this fails, which operation broke?Correct (one concept per test):
describe('UserService', () => {
describe('create', () => {
it('generates a unique id', async () => {
const user = await userService.create({ name: 'Alice', email: 'alice@test.com' })
expect(user.id).toBeDefined()
})
it('stores provided name and email', async () => {
const user = await userService.create({ name: 'Alice', email: 'alice@test.com' })
expect(user).toMatchObject({ name: 'Alice', email: 'alice@test.com' })
})
it('sets createdAt to current time', async () => {
const before = new Date()
const user = await userService.create({ name: 'Alice', email: 'alice@test.com' })
expect(user.createdAt.getTime()).toBeGreaterThanOrEqual(before.getTime())
})
})
describe('getById', () => {
it('returns previously created user', async () => {
const created = await userService.create({ name: 'Alice', email: 'alice@test.com' })
const fetched = await userService.getById(created.id)
expect(fetched).toEqual(created)
})
})
})Note: Multiple expect statements are fine when they verify the same logical assertion (e.g., checking multiple properties of a single return value).
Install with Tessl CLI
npx tessl i pantheon-ai/test-driven-development@0.2.4evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
references