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
Before coding, write down all the test cases you can think of. Work through them one at a time. This prevents scope creep during implementation and ensures edge cases aren't forgotten.
Incorrect (ad-hoc test discovery):
// Start coding without a plan
test('parses valid JSON', () => {
expect(parseConfig('{"key": "value"}')).toEqual({ key: 'value' })
})
// Pass, move on
test('handles nested objects', () => {
expect(parseConfig('{"a": {"b": 1}}')).toEqual({ a: { b: 1 } })
})
// Pass, move on, forget about error cases
// Ship to production, crashes on invalid input
// Edge cases discovered by users, not testsCorrect (test list first):
/*
* Test List for parseConfig:
* [x] parses valid JSON object
* [x] parses nested objects
* [x] parses arrays
* [ ] throws on invalid JSON syntax
* [ ] throws on non-object root (array, string, number)
* [ ] handles empty object {}
* [ ] handles unicode characters
* [ ] handles escaped quotes in strings
*/
// Work through list systematically
test('parses valid JSON object', () => {
expect(parseConfig('{"key": "value"}')).toEqual({ key: 'value' })
})
test('throws on invalid JSON syntax', () => {
expect(() => parseConfig('{invalid}')).toThrow('Invalid JSON')
})
test('throws on non-object root', () => {
expect(() => parseConfig('[1, 2, 3]')).toThrow('Config must be an object')
})
// Add new cases to list as you discover them
// Cross off completed testsManaging the test list:
Reference: Test Driven Development by Kent Beck
Install with Tessl CLI
npx tessl i pantheon-ai/test-driven-developmentevals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
references