tdd-workflow

Estrelas11

Forks2

Atualizado31 de março de 2026 às 05:10

Use when writing new features, fixing bugs, or refactoring tracker code. Enforces test-driven development with our Vitest + in-memory SQLite setup.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

moodler

moodler/liz-tracker

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·SOC 15-1253

SKILL.md

readonly

name	tdd-workflow
description	Use when writing new features, fixing bugs, or refactoring tracker code. Enforces test-driven development with our Vitest + in-memory SQLite setup.
origin	ECC-adapted

Test-Driven Development Workflow

When to Activate

Writing a new feature or MCP tool
Fixing a bug (write the failing test first)
Refactoring existing code
Adding a new space plugin

Core Principles

Red → Green → Refactor: Write a failing test, make it pass with minimal code, then clean up.
Test the behavior, not the implementation: Tests should describe what the code does, not how.
One assertion per test when possible: Makes failures easy to diagnose.

Tracker-Specific Test Setup

All tests use Vitest with in-memory SQLite:

import { describe, it, expect, beforeEach } from 'vitest';
import { _initTestTrackerDatabase } from './db';

describe('Feature Name', () => {
  let db: ReturnType<typeof _initTestTrackerDatabase>;

  beforeEach(() => {
    db = _initTestTrackerDatabase();
  });

  it('should do the expected thing', () => {
    // Arrange → Act → Assert
  });
});

TDD Workflow Steps

Understand the requirement — Read the work item description and comments
Write the test first — Create or extend a test file in src/**/*.test.ts
Run the test — npm test — verify it fails for the right reason
Write minimal implementation — Just enough to pass the test
Run all tests — npm test — verify nothing else broke
Refactor — Clean up while keeping tests green
Build check — npm run build — verify TypeScript compiles

Test File Conventions

Source file	Test file
`src/db.ts`	`src/db.test.ts`
`src/orchestrator.ts`	`src/orchestrator.test.ts`
`src/spaces/travel.ts`	`src/spaces/travel.test.ts`
`src/spaces/new-space.ts`	`src/spaces/new-space.test.ts`

What to Test

DB layer: State transitions, CRUD operations, actor classification, approval provenance
Orchestrator: Dispatch logic, error classification, schedule time gating
Space plugins: Parsers, sanitizers, deduplication logic
MCP tools: Input validation, authorization, expected outputs

Common Mistakes to Avoid

Testing implementation details (private function internals)
Skipping edge cases (empty inputs, null values, boundary conditions)
Not testing error paths (what happens when the DB query fails?)
Writing tests after the code is done (loses the design benefit of TDD)

Mais deste repositório

mesmo repositório

graphify

moodler/liz-tracker

Use for any question about a codebase, its architecture, file relationships, or project content — especially when graphify-out/ exists, where the question should be treated as a graphify query first. Turns any input (code, docs, papers, images, videos) into a persistent knowledge graph with god nodes, community detection, and query/path/explain tools.

2026-06-1111

mcp-tool-dev

moodler/liz-tracker

Guide for developing new MCP tools. Use when adding tools to mcp-server.ts or via space plugin mcpTools arrays. Covers Zod validation, actor handling, and test patterns.

2026-03-3111

node-sqlite-patterns

moodler/liz-tracker

Database patterns for better-sqlite3 with WAL mode. Query optimization, schema design, and migration patterns for the tracker's SQLite layer.

2026-03-3111

orchestrator-safe-dev

moodler/liz-tracker

Safety guidelines for modifying orchestrator code. Use when touching state transitions, SSE handling, session lifecycle, circuit breaker, safe restart, or dispatch logic in orchestrator.ts.

2026-03-3111

search-first

moodler/liz-tracker

Research-before-coding workflow. Search for existing patterns, helpers, and implementations in the tracker codebase before writing new code.

2026-03-3111

security-review

moodler/liz-tracker

Use when adding authentication, handling user input, working with secrets, creating API endpoints, or modifying security-sensitive code. General security checklist.

2026-03-3111

Test-Driven Development Workflow

When to Activate

Writing a new feature or MCP tool

Fixing a bug (write the failing test first)

Refactoring existing code

Adding a new space plugin

Core Principles

Red → Green → Refactor: Write a failing test, make it pass with minimal code, then clean up.

Test the behavior, not the implementation: Tests should describe what the code does, not how.

One assertion per test when possible: Makes failures easy to diagnose.

Tracker-Specific Test Setup

All tests use Vitest with in-memory SQLite:

import { describe, it, expect, beforeEach } from 'vitest'; import { _initTestTrackerDatabase } from './db'; describe('Feature Name', () => { let db: ReturnType<typeof _initTestTrackerDatabase>; beforeEach(() => { db = _initTestTrackerDatabase(); }); it('should do the expected thing', () => { // Arrange → Act → Assert }); });

TDD Workflow Steps

Understand the requirement — Read the work item description and comments

Write the test first — Create or extend a test file in src/**/*.test.ts

Run the test — npm test — verify it fails for the right reason

Write minimal implementation — Just enough to pass the test

Run all tests — npm test — verify nothing else broke

Refactor — Clean up while keeping tests green

Build check — npm run build — verify TypeScript compiles

Test File Conventions

Source file

Test file

src/db.ts

src/db.test.ts

src/orchestrator.ts

src/orchestrator.test.ts

src/spaces/travel.ts

src/spaces/travel.test.ts

src/spaces/new-space.ts

src/spaces/new-space.test.ts

What to Test

DB layer: State transitions, CRUD operations, actor classification, approval provenance

Orchestrator: Dispatch logic, error classification, schedule time gating

Space plugins: Parsers, sanitizers, deduplication logic

MCP tools: Input validation, authorization, expected outputs

Common Mistakes to Avoid

Testing implementation details (private function internals)

Skipping edge cases (empty inputs, null values, boundary conditions)

Not testing error paths (what happens when the DB query fails?)

Writing tests after the code is done (loses the design benefit of TDD)