MCP HubMCP Hub
스킬 목록으로 돌아가기

write-testthat-tests

pjt222
업데이트됨 Yesterday
3 조회
17
2
17
GitHub에서 보기
테스팅testing

정보

이 Claude Skill은 R 패키지 함수를 위한 포괄적인 testthat(에디션 3) 단위 테스트를 생성합니다. 이는 개발자가 새 함수에 대한 테스트를 추가하고, 기존 코드의 커버리지를 향상시키며, 버그 수정을 위한 회귀 테스트를 생성하거나 테스트 인프라를 설정하는 데 도움을 줍니다. 본 스킬은 높은 커버리지를 달성하기 위해 테스트 구조, 기대값, 픽스처, 목(Mock), 스냅샷 테스트 및 매개변수화된 테스트를 다룹니다.

빠른 설치

Claude Code

추천
기본
npx skills add pjt222/agent-almanac -a claude-code
플러그인 명령대체
/plugin add https://github.com/pjt222/agent-almanac
Git 클론대체
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/write-testthat-tests

Claude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요

문서


name: write-testthat-tests description: > Rパッケージ関数の包括的なtestthat(エディション3)テストを記述する。 テストの構成、期待値、フィクスチャ、モック、スナップショットテスト、 パラメータ化テスト、高いカバレッジ達成を網羅。新規パッケージ関数のテスト追加、 既存コードのテストカバレッジ向上、バグ修正のリグレッションテスト作成、 またはテストインフラの未整備なパッケージへの設定時に使用する。 locale: ja source_locale: en source_commit: 6f65f316 translator: claude-opus-4-6 translation_date: 2026-03-16 license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: r-packages complexity: intermediate language: R tags: r, testthat, testing, unit-tests, coverage

testthatテストの記述

testthatエディション3を使用してRパッケージ関数の包括的なテストを作成する。

使用タイミング

  • 新規パッケージ関数のテストを追加する時
  • 既存コードのテストカバレッジを向上させる時
  • バグ修正のリグレッションテストを作成する時
  • 新規パッケージのテストインフラを設定する時

入力

  • 必須: テスト対象のR関数
  • 必須: 期待される動作とエッジケース
  • 任意: テストフィクスチャまたはサンプルデータ
  • 任意: 目標カバレッジ率(デフォルト:80%)

手順

ステップ1: テストインフラの設定

まだ設定していない場合:

usethis::use_testthat(edition = 3)

これによりtests/testthat.Rtests/testthat/ディレクトリが作成される。

期待結果: tests/testthat.Rtests/testthat/ディレクトリが作成される。DESCRIPTIONにConfig/testthat/edition: 3が設定される。

失敗時: usethisが利用できない場合、tests/testthat.Rを手動で作成しlibrary(testthat); library(packagename); test_check("packagename")を含め、tests/testthat/ディレクトリを追加する。

ステップ2: テストファイルの作成

usethis::use_test("function_name")

tests/testthat/test-function_name.Rにテンプレートが作成される。

期待結果: tests/testthat/test-function_name.Rにプレースホルダーのtest_that()ブロックが作成され、すぐに記述できる状態になる。

失敗時: usethis::use_test()が利用できない場合、ファイルを手動で作成する。test-<function_name>.Rという命名規則に従うこと。

ステップ3: 基本テストの記述

test_that("weighted_mean computes correct result", {
  expect_equal(weighted_mean(1:3, c(1, 1, 1)), 2)
  expect_equal(weighted_mean(c(10, 20), c(1, 3)), 17.5)
})

test_that("weighted_mean handles NA values", {
  expect_equal(weighted_mean(c(1, NA, 3), c(1, 1, 1), na.rm = TRUE), 2)
  expect_true(is.na(weighted_mean(c(1, NA, 3), c(1, 1, 1), na.rm = FALSE)))
})

test_that("weighted_mean validates input", {
  expect_error(weighted_mean("a", 1), "numeric")
  expect_error(weighted_mean(1:3, 1:2), "length")
})

期待結果: 基本テストが、典型的な入力に対する正しい出力、NAの処理動作、入力バリデーションのエラーメッセージをカバーしている。

失敗時: テストがすぐに失敗する場合、関数が読み込まれているか確認する(devtools::load_all())。エラーメッセージが一致しない場合、expect_error()で正確な文字列の代わりに正規表現パターンを使用する。

ステップ4: エッジケースのテスト

test_that("weighted_mean handles edge cases", {
  # 空の入力
  expect_error(weighted_mean(numeric(0), numeric(0)))

  # 単一の値
  expect_equal(weighted_mean(5, 1), 5)

  # ゼロの重み
  expect_true(is.nan(weighted_mean(1:3, c(0, 0, 0))))

  # 非常に大きな値
  expect_equal(weighted_mean(c(1e15, 1e15), c(1, 1)), 1e15)

  # 負の重み
  expect_error(weighted_mean(1:3, c(-1, 1, 1)))
})

期待結果: エッジケースがカバーされている:空の入力、単一の値、ゼロの重み、極端な値、無効な入力。各エッジケースに明確な期待動作がある。

失敗時: 関数がエッジケースを期待通りに処理しない場合、関数を修正するかテストを調整するかを判断する。曖昧なケースの意図する動作を文書化する。

ステップ5: 複雑なテストにフィクスチャを使用

テストデータ用にtests/testthat/fixtures/を作成する:

# tests/testthat/helper.R(自動的に読み込まれる)
create_test_data <- function() {
  data.frame(
    x = c(1, 2, 3, NA, 5),
    group = c("a", "a", "b", "b", "b")
  )
}
# テストファイル内
test_that("process_data works with grouped data", {
  test_data <- create_test_data()
  result <- process_data(test_data)
  expect_s3_class(result, "data.frame")
  expect_equal(nrow(result), 2)
})

期待結果: フィクスチャが複数のテストファイルにわたって一貫したテストデータを提供する。tests/testthat/helper.Rのヘルパー関数はtestthatによって自動的に読み込まれる。

失敗時: ヘルパー関数が見つからない場合、ファイルがhelpers.Rではなくhelper.Rという名前でtests/testthat/にあることを確認する。必要に応じてRセッションを再起動する。

ステップ6: 外部依存関係のモック

test_that("fetch_data handles API errors", {
  local_mocked_bindings(
    api_call = function(...) stop("Connection refused")
  )
  expect_error(fetch_data("endpoint"), "Connection refused")
})

test_that("fetch_data returns parsed data", {
  local_mocked_bindings(
    api_call = function(...) list(data = list(value = 42))
  )
  result <- fetch_data("endpoint")
  expect_equal(result$value, 42)
})

期待結果: 外部依存関係(API、データベース、ネットワーク呼び出し)がモック化され、テストが実際の接続なしで実行される。モックの戻り値が関数のデータ処理ロジックを検証する。

失敗時: local_mocked_bindings()が失敗する場合、モック化される関数がテストスコープからアクセス可能か確認する。他のパッケージの関数には.package引数を使用する。

ステップ7: 複雑な出力のスナップショットテスト

test_that("format_report produces expected output", {
  expect_snapshot(format_report(test_data))
})

test_that("plot_results creates expected plot", {
  expect_snapshot_file(
    save_plot(plot_results(test_data), "test-plot.png"),
    "expected-plot.png"
  )
})

期待結果: スナップショットファイルがtests/testthat/_snaps/に作成される。最初の実行でベースラインが作成され、以降の実行はそれと比較される。

失敗時: 意図的な変更後にスナップショットが失敗する場合、testthat::snapshot_accept()で更新する。クロスプラットフォームの違いには、プラットフォーム固有のスナップショットを保持するためにvariantパラメータを使用する。

ステップ8: スキップ条件の使用

test_that("database query works", {
  skip_on_cran()
  skip_if_not(has_db_connection(), "No database available")

  result <- query_db("SELECT 1")
  expect_equal(result[[1]], 1)
})

test_that("parallel computation works", {
  skip_on_os("windows")
  skip_if(parallel::detectCores() < 2, "Need multiple cores")

  result <- parallel_compute(1:100)
  expect_length(result, 100)
})

期待結果: 特別な環境(ネットワーク、データベース、複数コア)が必要なテストが適切なスキップ条件で保護されている。これらのテストはローカルでは実行されるが、CRANや制限されたCI環境ではスキップされる。

失敗時: テストがCRANやCIでは失敗するがローカルではパスする場合、test_that()ブロックの先頭に適切なskip_on_cran()skip_on_os()、またはskip_if_not()ガードを追加する。

ステップ9: テストの実行とカバレッジの確認

# すべてのテストを実行
devtools::test()

# 特定のテストファイルを実行
devtools::test_active_file()  # RStudioで
testthat::test_file("tests/testthat/test-function_name.R")

# カバレッジを確認
covr::package_coverage()
covr::report()

期待結果: devtools::test()ですべてのテストがパスする。カバレッジレポートが目標率(>80%を目標)を達成していることを示す。

失敗時: テストが失敗した場合、テスト出力を読んで特定のアサーション失敗を確認する。カバレッジが目標を下回る場合はcovr::report()を使用してテストされていないコードパスを特定し、テストを追加する。

バリデーション

  • devtools::test()ですべてのテストがパスする
  • カバレッジが目標率を超えている
  • エクスポートされるすべての関数に少なくとも1つのテストがある
  • エラー条件がテストされている
  • エッジケースがカバーされている(NA、NULL、空、境界値)
  • テストが外部状態や実行順序に依存していない

よくある落とし穴

  • テストが互いに依存している: 各test_that()ブロックは独立していなければならない
  • ハードコードされたファイルパス: テストフィクスチャにはtestthat::test_path()を使用する
  • 浮動小数点の比較: expect_identical()ではなくexpect_equal()(許容誤差あり)を使用する
  • プライベート関数のテスト: 可能な限りパブリックAPIを通じてテストする。:::は控えめに使用する
  • CIでのスナップショットテスト: スナップショットはプラットフォーム依存。クロスプラットフォームにはvariantパラメータを使用する
  • skip_on_cran()の忘れ: ネットワーク、データベース、または長い実行時間が必要なテストはCRANでスキップしなければならない

# パターン:テストファイルはR/ファイルを反映する
# R/weighted_mean.R -> tests/testthat/test-weighted_mean.R

# パターン:説明的なテスト名
test_that("weighted_mean returns NA when na.rm = FALSE and input contains NA", {
  result <- weighted_mean(c(1, NA), c(1, 1), na.rm = FALSE)
  expect_true(is.na(result))
})

# パターン:警告のテスト
test_that("deprecated_function emits deprecation warning", {
  expect_warning(deprecated_function(), "deprecated")
})

関連スキル

  • create-r-package - パッケージ作成の一部としてテストインフラを設定する
  • write-roxygen-docs - テストする関数のドキュメント化
  • setup-github-actions-ci - プッシュ時にテストを自動実行する
  • submit-to-cran - CRANはすべてのプラットフォームでテストのパスを要求する

GitHub 저장소

pjt222/agent-almanac
경로: i18n/ja/skills/write-testthat-tests
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

연관 스킬

evaluating-llms-harness

테스팅

이 Claude Skill은 MMLU, GSM8K를 포함한 60개 이상의 표준화된 학술 과제에서 LLM 성능을 벤치마크하기 위해 lm-evaluation-harness를 실행합니다. 개발자들이 모델 품질을 비교하고, 학습 진행 상황을 추적하거나 학술 결과를 보고할 수 있도록 설계되었습니다. 이 도구는 HuggingFace와 vLLM 모델을 포함한 다양한 백엔드를 지원합니다.

스킬 보기

cloudflare-cron-triggers

테스팅

이 스킬은 cron 표현식을 사용하여 Worker를 스케줄링하기 위한 Cloudflare Cron Triggers 구현에 관한 포괄적인 지식을 제공합니다. 주기적 작업, 유지보수 작업, 자동화된 워크플로우 설정 방법을 다루며, 잘못된 cron 표현식이나 시간대 문제 같은 일반적인 이슈들을 해결하는 방법을 포함합니다. 개발자들은 이를 통해 스케줄된 핸들러 구성, cron 트리거 테스트, Workflows 및 Green Compute와의 연동 작업을 수행할 수 있습니다.

스킬 보기

webapp-testing

테스팅

이 Claude Skill은 Python 스크립트를 통해 로컬 웹 애플리케이션을 테스트하기 위한 Playwright 기반 툴킷을 제공합니다. 프론트엔드 검증, UI 디버깅, 스크린샷 캡처, 로그 확인 기능을 지원하며 서버 라이프사이클을 관리합니다. 브라우저 자동화 작업에 사용하되 컨텍스트 오염을 방지하기 위해 소스 코드를 읽지 않고 스크립트를 직접 실행하세요.

스킬 보기

finishing-a-development-branch

테스팅

이 스킬은 테스트 통과를 확인한 후 체계적인 통합 옵션을 제시하여 개발자가 완성된 작업을 마무리하도록 돕습니다. 구현이 완료된 후 머지, PR 생성, 브랜치 정리와 같은 워크플로우를 안내합니다. 코드가 준비되고 테스트가 완료되었을 때 개발 프로세스를 체계적으로 마무리하기 위해 사용하세요.

스킬 보기