Skip to content

TDD.md

Latest commit

 

History

History
103 lines (71 loc) · 3.56 KB

TDD.md

File metadata and controls

103 lines (71 loc) · 3.56 KB

TDD.md

This document outlines the Test-Driven Development methodology and core development principles for the wowpress-cs project.

CORE DEVELOPMENT PRINCIPLES

  • Always follow the TDD cycle: Red → Green → Refactor
  • Write the simplest failing test first
  • Implement the minimum code needed to make tests pass
  • Refactor only after tests are passing
  • Follow Beck's "Tidy First" approach by separating structural changes from behavioral changes
  • Maintain high code quality throughout development

TDD METHODOLOGY GUIDANCE

  • Start by writing a failing test that defines a small increment of functionality
  • Use meaningful test names that describe behavior (e.g., "shouldSumTwoPositiveNumbers")
  • Make test failures clear and informative
  • Write just enough code to make the test pass - no more
  • Once tests pass, consider if refactoring is needed
  • Repeat the cycle for new functionality

TIDY FIRST APPROACH

Separate all changes into two distinct types:

1. STRUCTURAL CHANGES

Rearranging code without changing behavior (renaming, extracting methods, moving code)

2. BEHAVIORAL CHANGES

Adding or modifying actual functionality

Rules:

  • Never mix structural and behavioral changes in the same commit
  • Always make structural changes first when both are needed
  • Validate structural changes do not alter behavior by running tests before and after

COMMIT DISCIPLINE

Only commit when:

  1. ALL tests are passing
  2. ALL compiler/linter warnings have been resolved
  3. The change represents a single logical unit of work
  4. Commit messages clearly state whether the commit contains structural or behavioral changes
  • Use small, frequent commits rather than large, infrequent ones

CODE QUALITY STANDARDS

  • Eliminate duplication ruthlessly
  • Express intent clearly through naming and structure
  • Make dependencies explicit
  • Keep methods small and focused on a single responsibility
  • Minimize state and side effects
  • Use the simplest solution that could possibly work

REFACTORING GUIDELINES

  • Refactor only when tests are passing (in the "Green" phase)
  • Use established refactoring patterns with their proper names
  • Make one refactoring change at a time
  • Run tests after each refactoring step
  • Prioritize refactorings that remove duplication or improve clarity

EXAMPLE WORKFLOW

When approaching a new feature:

  1. Write a simple failing test for a small part of the feature
  2. Implement the bare minimum to make it pass
  3. Run tests to confirm they pass (Green)
  4. Make any necessary structural changes (Tidy First), running tests after each change
  5. Commit structural changes separately
  6. Add another test for the next small increment of functionality
  7. Repeat until the feature is complete, committing behavioral changes separately from structural ones

Follow this process precisely, always prioritizing clean, well-tested code over quick implementation.

Always write one test at a time, make it run, then improve structure. Always run all the tests (except long-running tests) each time.

Integration with Project Standards

This TDD methodology works in conjunction with:

TDD Commands

# Run tests in TDD cycle
bun test                    # Run all tests
bun test:unit              # Run unit tests only
bun test path/to/test.ts   # Run specific test file

# Quality checks before commit
bun run lint:fix && bun run typecheck && bun run test