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

write-testthat-tests

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

정보

이 스킬은 R 패키지 함수를 위한 포괄적인 testthat(3판) 단위 테스트를 생성합니다. 개발자가 새로운 함수에 대한 테스트를 추가하거나, 코드 커버리지를 높이고, 회귀 테스트를 작성하거나, 처음부터 테스트 인프라를 설정하는 데 도움을 줍니다. 주요 기능으로는 테스트 구성, 어설션, 픽스처, 목킹, 스냅샷 테스트 및 매개변수화된 테스트가 포함됩니다.

빠른 설치

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: > Escribir pruebas exhaustivas con testthat (edición 3) para funciones de paquetes R. Cubre organización de pruebas, aserciones, fixtures, mocking, pruebas de snapshot, pruebas parametrizadas y obtención de alta cobertura. Usar al añadir pruebas para nuevas funciones del paquete, aumentar la cobertura de pruebas del código existente, escribir pruebas de regresión para corrección de errores, o configurar la infraestructura de pruebas para un paquete que carece de ella. locale: es 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

Escribir Pruebas con testthat

Crear pruebas exhaustivas para funciones de paquetes R usando testthat edición 3.

Cuándo Usar

  • Añadir pruebas para nuevas funciones del paquete
  • Aumentar la cobertura de pruebas del código existente
  • Escribir pruebas de regresión para corrección de errores
  • Configurar la infraestructura de pruebas para un nuevo paquete

Entradas

  • Obligatorio: Funciones R a probar
  • Obligatorio: Comportamiento esperado y casos límite
  • Opcional: Fixtures de prueba o datos de muestra
  • Opcional: Porcentaje de cobertura objetivo (predeterminado: 80%)

Procedimiento

Paso 1: Configurar la Infraestructura de Pruebas

Si aún no está hecho:

usethis::use_testthat(edition = 3)

Esto crea tests/testthat.R y el directorio tests/testthat/.

Esperado: Se crean tests/testthat.R y el directorio tests/testthat/. DESCRIPTION tiene Config/testthat/edition: 3 configurado.

En caso de fallo: Si usethis no está disponible, crear manualmente tests/testthat.R con el contenido library(testthat); library(packagename); test_check("packagename") y el directorio tests/testthat/.

Paso 2: Crear el Archivo de Prueba

usethis::use_test("function_name")

Esto crea tests/testthat/test-function_name.R con una plantilla.

Esperado: Archivo de prueba creado en tests/testthat/test-function_name.R con un bloque test_that() de marcador listo para completar.

En caso de fallo: Si usethis::use_test() no está disponible, crear el archivo manualmente. Seguir la convención de nomenclatura test-<function_name>.R.

Paso 3: Escribir Pruebas Básicas

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")
})

Esperado: Las pruebas básicas cubren la salida correcta para entradas típicas, el comportamiento con valores NA y los mensajes de error de validación de entradas.

En caso de fallo: Si las pruebas fallan inmediatamente, verificar que la función está cargada (devtools::load_all()). Si los mensajes de error no coinciden, usar un patrón regex en expect_error() en lugar de una cadena exacta.

Paso 4: Probar Casos Límite

test_that("weighted_mean handles edge cases", {
  # Empty input
  expect_error(weighted_mean(numeric(0), numeric(0)))

  # Single value
  expect_equal(weighted_mean(5, 1), 5)

  # Zero weights
  expect_true(is.nan(weighted_mean(1:3, c(0, 0, 0))))

  # Very large values
  expect_equal(weighted_mean(c(1e15, 1e15), c(1, 1)), 1e15)

  # Negative weights
  expect_error(weighted_mean(1:3, c(-1, 1, 1)))
})

Esperado: Se cubren los casos límite: entrada vacía, valores únicos, pesos cero, valores extremos y entradas inválidas. Cada caso límite tiene un comportamiento esperado claro.

En caso de fallo: Si la función no gestiona un caso límite como se espera, decidir si corregir la función o ajustar la prueba. Documentar el comportamiento previsto para los casos ambiguos.

Paso 5: Usar Fixtures para Pruebas Complejas

Crear tests/testthat/fixtures/ para datos de prueba:

# tests/testthat/helper.R (cargado automáticamente)
create_test_data <- function() {
  data.frame(
    x = c(1, 2, 3, NA, 5),
    group = c("a", "a", "b", "b", "b")
  )
}
# En el archivo de prueba
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)
})

Esperado: Las fixtures proporcionan datos de prueba consistentes en múltiples archivos de prueba. Las funciones auxiliares en tests/testthat/helper.R se cargan automáticamente por testthat.

En caso de fallo: Si las funciones auxiliares no se encuentran, asegurarse de que el archivo se llama helper.R (no helpers.R) y está en tests/testthat/. Reiniciar la sesión R si es necesario.

Paso 6: Simular Dependencias Externas

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)
})

Esperado: Las dependencias externas (APIs, bases de datos, llamadas de red) se simulan para que las pruebas se ejecuten sin conexiones reales. Los valores de retorno simulados ejercitan la lógica de procesamiento de datos de la función.

En caso de fallo: Si local_mocked_bindings() falla, asegurarse de que la función simulada es accesible en el ámbito de la prueba. Para funciones de otros paquetes, usar el argumento .package.

Paso 7: Pruebas de Snapshot para Salidas Complejas

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"
  )
})

Esperado: Los archivos de snapshot se crean en tests/testthat/_snaps/. La primera ejecución crea la línea base; las ejecuciones siguientes comparan con ella.

En caso de fallo: Si los snapshots fallan tras un cambio intencionado, actualizarlos con testthat::snapshot_accept(). Para diferencias entre plataformas, usar el parámetro variant para mantener snapshots específicos de cada plataforma.

Paso 8: Usar Condiciones de Omisión

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)
})

Esperado: Las pruebas que requieren entornos especiales (red, base de datos, múltiples núcleos) están correctamente protegidas con condiciones de omisión. Estas pruebas se ejecutan localmente pero se omiten en CRAN o entornos de CI restringidos.

En caso de fallo: Si las pruebas fallan en CRAN o CI pero pasan localmente, añadir el guard skip_on_cran(), skip_on_os() o skip_if_not() apropiado al inicio del bloque test_that().

Paso 9: Ejecutar Pruebas y Verificar Cobertura

# Ejecutar todas las pruebas
devtools::test()

# Ejecutar archivo de prueba específico
devtools::test_active_file()  # en RStudio
testthat::test_file("tests/testthat/test-function_name.R")

# Verificar cobertura
covr::package_coverage()
covr::report()

Esperado: Todas las pruebas pasan con devtools::test(). El informe de cobertura muestra que se alcanza el porcentaje objetivo (apuntar a >80%).

En caso de fallo: Si las pruebas fallan, leer la salida de las pruebas para los fallos de aserción específicos. Si la cobertura está por debajo del objetivo, usar covr::report() para identificar las rutas de código no probadas y añadir pruebas para ellas.

Validación

  • Todas las pruebas pasan con devtools::test()
  • La cobertura supera el porcentaje objetivo
  • Cada función exportada tiene al menos una prueba
  • Se prueban las condiciones de error
  • Se cubren los casos límite (NA, NULL, vacío, valores en los límites)
  • Ninguna prueba depende de estado externo ni del orden de ejecución

Errores Comunes

  • Pruebas que dependen unas de otras: Cada bloque test_that() debe ser independiente
  • Rutas de archivo codificadas: Usar testthat::test_path() para los fixtures de prueba
  • Comparación de punto flotante: Usar expect_equal() (tiene tolerancia) no expect_identical()
  • Probar funciones privadas: Probar a través de la API pública cuando sea posible. Usar ::: con moderación.
  • Pruebas de snapshot en CI: Los snapshots son sensibles a la plataforma. Usar el parámetro variant para plataformas cruzadas.
  • Olvidar skip_on_cran(): Las pruebas que requieren red, bases de datos o ejecución larga deben omitirse en CRAN

Ejemplos

# Patrón: el archivo de prueba refleja el archivo R/
# R/weighted_mean.R -> tests/testthat/test-weighted_mean.R

# Patrón: nombres de prueba descriptivos
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))
})

# Patrón: probar advertencias
test_that("deprecated_function emits deprecation warning", {
  expect_warning(deprecated_function(), "deprecated")
})

Habilidades Relacionadas

  • create-r-package - configurar la infraestructura de pruebas como parte de la creación del paquete
  • write-roxygen-docs - documentar las funciones que se prueban
  • setup-github-actions-ci - ejecutar pruebas automáticamente al hacer push
  • submit-to-cran - CRAN requiere que las pruebas pasen en todas las plataformas

GitHub 저장소

pjt222/agent-almanac
경로: i18n/es/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 생성, 브랜치 정리와 같은 워크플로우를 안내합니다. 코드가 준비되고 테스트가 완료되었을 때 개발 프로세스를 체계적으로 마무리하기 위해 사용하세요.

스킬 보기