tdd-workflow

Enforce test-first development for R packages using testthat Edition 3.

1|1|Updated May 5, 2026
One-click install
npx skills add https://github.com/cynkra/cynkra.ai.day --skill tdd-workflow-cynkra
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: tdd-workflow
Source: https://github.com/cynkra/cynkra.ai.day/tree/main/claude-code-r-skills/.claude/skills/tdd-workflow
Command: npx skills add https://github.com/cynkra/cynkra.ai.day --skill tdd-workflow-cynkra

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents regressions and brittle refactors in R projects by forcing test-first development with strong test coverage expectations.

Core Features & Use Cases

  • Test-First Development (TDD): Always write tests before implementing code, so requirements are explicit and enforceable.
  • Coverage Guardrails: Targets 80%+ coverage, with 100% coverage expectations for statistical calculations and data validation paths.
  • Structured Testing Patterns: Promotes consistent test naming/structure across unit, integration, and snapshot tests, using testthat (Edition 3) features.
  • Use Cases: Writing new functions, fixing bugs, refactoring existing code, adding model types, building data pipelines, and developing Shiny components.

Quick Start

Activate this workflow by using usethis::use_test("your_function") to create a failing test first, then implement the smallest code change needed to make the test pass.

Frequently Asked Questions about tdd-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce test-driven development in R packages to prevent regressions?

Test-driven development in R packages is enforced by writing failing tests with testthat before implementing code, targeting 80%+ coverage, and using testthat Edition 3 patterns to reduce regressions.

What is the best way to structure unit and integration tests for R data pipelines?

Structure unit and integration tests for R data pipelines using testthat Edition 3 patterns, ensuring tests are written before code with 80%+ coverage and stricter expectations for validation paths.

Does testthat work with snapshot testing for Shiny components in R?

testthat works with snapshot testing for Shiny components in R by using Edition 3 modern expectation helpers to capture and verify UI outputs, enforcing test-first discipline to prevent refactoring regressions.

What code coverage percentage should I target for statistical calculations in R?

Code coverage for statistical calculations in R should target 80%+ overall, with 100% coverage expectations specifically for calculation and data validation paths to prevent regressions.

How do I start writing tests before code when fixing bugs in an R package?

Start writing tests before code when fixing bugs in an R package by using usethis::use_test("your_function") to create a failing test first, then implement the smallest code change needed to pass.

When should I not use test-first development for refactoring R code?

Test-first development for refactoring R code is not suitable when existing test coverage is entirely absent and immediate hotfixes are required, as the workflow mandates writing failing tests before any implementation.