domains / software-engineering / test-driven-development / tdd-workflow

tdd-workflow

Skill card

combined

The two skills cover the same high-level concept (TDD) but diverge significantly in scope and implementation. The first skill (sickn33) is a language-agnostic, conceptual guide to the RED-GREEN-REFACTOR cycle, focusing on principles, anti-patterns, and AI-agent roles. The second skill (brycewang-stanford) is a specific, technical implementation guide for R using the `testthat` package, including code examples, coverage requirements (80%+), and specific API usage (Edition 3). Neither is a reproduction of the other; the first lacks the R-specific tooling, and the second lacks the general conceptual framework and AI-agent patterns. Combining them provides a complete workflow: the conceptual foundation from the first and the concrete R implementation from the second.

Repositories

Other copies

Combined skill

---
name: tdd-workflow
description: "Test-Driven Development workflow principles and R implementation. RED-GREEN-REFACTOR cycle with testthat specifics."
---

# TDD Workflow

> Write tests first, code second.

## 1. The TDD Cycle

1. **RED**: Write a failing test.
2. **GREEN**: Write minimal code to pass the test.
3. **REFACTOR**: Improve code quality while keeping tests green.

## 2. Core Principles

- **Tests Before Code**: Always write the test first.
- **Minimal Code**: Write only enough code to pass the current test (YAGNI).
- **Refactor Safely**: Only refactor when all tests are green.
- **Coverage**: Aim for high coverage (e.g., 80%+ general, 100% for critical logic/statistics).

## 3. R Implementation (testthat)

### Setup
```r
usethis::use_testthat(3)
```

### Test Structure
Use `test_that()` for unit tests and `describe()`/`it()` for BDD-style tests.

```r
test_that("function works", {
  # Arrange
  data <- tibble(x = 1:10)
  # Act
  result <- my_function(data)
  # Assert
  expect_equal(nrow(result), 10)
})
```

### Key Practices
- **Self-Sufficient Tests**: Each test must be independent and runnable in isolation.
- **Duplication Over Factoring**: Duplicate setup code in tests for clarity rather than extracting it.
- **Use `devtools::load_all()`**: During development, use this instead of `library()` to expose unexported functions.
- **Snapshot Testing**: Use `expect_snapshot()` for complex outputs or error messages.

## 4. Anti-Patterns

- Skipping the RED phase.
- Writing tests after implementation.
- Over-engineering the initial solution.
- Testing implementation details instead of behavior.

## 5. When to Use

- New features.
- Bug fixes (write a failing test first).
- Complex logic or refactoring.