r-testing

Defines testthat 3e conventions, test organization, and coverage thresholds for R projects.

Updated Jul 29, 2026
One-click install
npx skills add https://github.com/chris-prener/dev-kit --skill r-testing-chris-prener
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: r-testing
Source: https://github.com/chris-prener/dev-kit/tree/main/dev-kit/skills/r-testing
Command: npx skills add https://github.com/chris-prener/dev-kit --skill r-testing-chris-prener

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? R projects often lack consistent testing conventions, leading to disorganized test files, unclear coverage expectations, and fragile tests that break across environments. This Skill standardizes how tests are written, named, organized, and measured in R projects using testthat 3rd edition. ## Core Features & Use Cases - Test Framework Conventions: Enforces testthat 3e with clear patterns for unit tests, integration tests, BDD-style describe/it blocks, and snapshot testing for reports and plots. - Directory and Naming Standards: Maps source files like R/functions/utils_data.R to test files like tests/testthat/test-utils-data.R, with helper.R, setup.R, and fixtures/ organization. - Coverage Requirements: Defines an 80% line-coverage advisory threshold and 100% exported-function coverage, with covr commands for reporting. - Use Case: When adding a new data transformation function to an R package, use this Skill to generate a properly named test file with unit tests, edge-case coverage, and fixtures that follow project conventions. ## Quick Start Write testthat 3e tests for my R function calculate_order_total following the project testing conventions.

Frequently Asked Questions about r-testing

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

FAQPage Schema
How do I write unit tests in R with testthat?▼

Use test_that() blocks with one behavior per test and descriptive names like "function_name() handles edge case X". For BDD style, use describe() and it() blocks. Always use testthat 3rd edition by declaring Config/testthat/edition: 3 in DESCRIPTION.

How should I name and organize test files in an R package?▼

Name test files as test- plus the source file name with hyphens, so R/functions/utils_data.R maps to tests/testthat/test-utils-data.R. Place shared setup in helper.R, static test data in fixtures/, and snapshot output in _snaps/.

How do I test plots and complex output in R?▼

Use snapshot testing with testthat::expect_snapshot() for printed output and expect_snapshot_file() for saved plot files. Add skip_on_ci() when rendering may differ across platforms, and store snapshots in the auto-generated _snaps/ directory.

What code coverage threshold should R packages meet?▼

This convention sets 80% line coverage as an advisory threshold tracked in CI, plus 100% coverage of exported functions meaning every exported function has at least one test. Measure coverage with covr::package_coverage() and generate reports with covr::report().

Why should I avoid library() and setwd() in R test files?▼

Using library() in tests creates undeclared dependencies; instead use pkg::function() or rely on DESCRIPTION. setwd() breaks test isolation, so use withr::local_dir() for temporary directory changes and testthat::test_path() for fixture references.