MCP HubMCP Hub
Retour aux compétences

test-shiny-app

pjt222
Mis à jour 2 days ago
6 vues
17
2
17
Voir sur GitHub
Teststesting

À propos

Cette compétence aide les développeurs à tester les applications Shiny en utilisant shinytest2 pour les tests de navigateur de bout en bout et testServer() pour les tests unitaires de la logique des modules. Elle prend en charge les tests par instantané, l'intégration en CI et la simulation de services externes. Utilisez-la pour ajouter des tests à des applications existantes, établir une stratégie de test pour de nouveaux projets, exécuter des tests de régression avant une refactorisation, ou intégrer les tests dans les pipelines CI/CD.

Installation rapide

Claude Code

Recommandé
Principal
npx skills add pjt222/agent-almanac -a claude-code
Commande PluginAlternatif
/plugin add https://github.com/pjt222/agent-almanac
Git CloneAlternatif
git clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/test-shiny-app

Copiez et collez cette commande dans Claude Code pour installer cette compétence

Documentation

Test Shiny App

Comprehensive testing: shinytest2 (e2e) + testServer() (unit).

Use When

  • Add tests to existing Shiny app
  • Set up strategy for new Shiny project
  • Regression tests before refactor
  • Integrate into CI/CD

In

  • Required: Path to Shiny app
  • Required: Test scope (unit, e2e, both)
  • Optional: Snapshot testing (default: yes for e2e)
  • Optional: CI platform (GH Actions, GitLab CI)
  • Optional: Modules to test in isolation

Do

Step 1: Install Test Deps

install.packages("shinytest2")

# For golem apps, add as a Suggests dependency
usethis::use_package("shinytest2", type = "Suggests")

# Set up testthat infrastructure if not present
usethis::use_testthat(edition = 3)

Got: shinytest2 installed + testthat dir structure in place.

If err: shinytest2 needs chromote (headless Chrome). Install Chrome/Chromium. WSL: sudo apt install -y chromium-browser. Verify w/ chromote::find_chrome().

Step 2: testServer() Unit Tests

Create tests/testthat/test-mod_dashboard.R:

test_that("dashboard module filters data correctly", {
  testServer(dataFilterServer, args = list(
    data = reactive(iris),
    columns = c("Species", "Sepal.Length")
  ), {
    # Set inputs
    session$setInputs(column = "Species")
    session$setInputs(value_select = "setosa")
    session$setInputs(apply = 1)

    # Check output
    result <- filtered()
    expect_equal(nrow(result), 50)
    expect_true(all(result$Species == "setosa"))
  })
})

test_that("dashboard module handles empty data", {
  testServer(dataFilterServer, args = list(
    data = reactive(iris[0, ]),
    columns = c("Species")
  ), {
    # Module should not error on empty data
    expect_no_error(session$setInputs(column = "Species"))
  })
})

Patterns:

  • testServer() tests module server logic w/o browser
  • Pass reactive args via args list
  • session$setInputs() simulates user
  • Access reactive returns directly by name
  • Test edge: empty data, NULL inputs, invalid values

Got: Module tests pass devtools::test().

If err: testServer() errs "not a module server function" → fn must use moduleServer() internally. session$setInputs() doesn't trigger reactives → add session$flushReact() after.

Step 3: shinytest2 E2E Tests

Create tests/testthat/test-app-e2e.R:

test_that("app loads and displays initial state", {
  # For golem apps
  app <- AppDriver$new(
    app_dir = system.file(package = "myapp"),
    name = "initial-load",
    height = 800,
    width = 1200
  )
  on.exit(app$stop(), add = TRUE)

  # Wait for app to load
  app$wait_for_idle(timeout = 10000)

  # Check that key elements exist
  app$expect_values()
})

test_that("filter interaction updates the table", {
  app <- AppDriver$new(
    app_dir = system.file(package = "myapp"),
    name = "filter-interaction"
  )
  on.exit(app$stop(), add = TRUE)

  # Interact with the app
  app$set_inputs(`filter1-column` = "cyl")
  app$wait_for_idle()

  app$set_inputs(`filter1-apply` = "click")
  app$wait_for_idle()

  # Snapshot the output values
  app$expect_values(output = "table")
})

Patterns:

  • AppDriver$new() launches in headless Chrome
  • Always on.exit(app$stop()) for cleanup
  • Module input IDs: "moduleId-inputId"
  • app$expect_values() creates/cmps snapshot files
  • app$wait_for_idle() ensures reactive updates complete

Got: E2E tests create snapshot files in tests/testthat/_snaps/.

If err: Chrome not found → set CHROMOTE_CHROME env to path. Snapshots fail CI but pass local → platform-dep rendering diffs; use app$expect_values() for data, not app$expect_screenshot() for visual.

Step 4: Record Test Interactively (Optional)

shinytest2::record_test("path/to/app")

Opens app in browser w/ recording panel. Interact, click "Save test" → auto-gen test code.

Got: Test file generated in tests/testthat/ w/ recorded interactions.

If err: Recorder doesn't open → check app runs w/ shiny::runApp() first. Recorder needs working app.

Step 5: Snapshot Mgmt

For snapshot tests, manage expected:

# Accept new/changed snapshots after review
testthat::snapshot_accept("test-app-e2e")

# Review snapshot differences
testthat::snapshot_review("test-app-e2e")

Add snapshot dirs to VCS:

tests/testthat/_snaps/    # Committed — contains expected values

Got: Snapshot files tracked in git for regression detection.

If err: Snapshots change unexpectedly → run testthat::snapshot_review() for diffs. Accept intentional changes w/ testthat::snapshot_accept().

Step 6: CI Integration

Add to .github/workflows/R-CMD-check.yaml | dedicated workflow:

- name: Install system dependencies
  run: |
    sudo apt-get update
    sudo apt-get install -y chromium-browser

- name: Set Chrome path
  run: echo "CHROMOTE_CHROME=$(which chromium-browser)" >> $GITHUB_ENV

- name: Run tests
  run: |
    Rscript -e 'devtools::test()'

Golem apps → install pkg before testing:

- name: Install app package
  run: Rscript -e 'devtools::install()'

Got: Tests pass in CI w/ headless Chrome.

If err: Common: Chrome not installed (add apt-get), display server missing (shinytest2 headless default so usually no issue), timeout on slow runners (↑ timeout in AppDriver$new()).

Check

  • devtools::test() runs all w/o errors
  • testServer() covers module server logic
  • shinytest2 covers key user workflows
  • Snapshot files committed
  • Tests pass in CI
  • Edge cases tested (empty data, NULL inputs, errs)

Traps

  • Test UI rendering vs logic: Prefer testServer() for logic + app$expect_values() for data. Only app$expect_screenshot() when visual matters — screenshots brittle across platforms.
  • Module ID format e2e: AppDriver uses "moduleId-inputId" (hyphen), NOT "moduleId.inputId".
  • Flaky timing: Always app$wait_for_idle() after app$set_inputs(). Without → assertions may run before reactive updates.
  • Snapshot drift: Don't commit snapshots from diff platforms (Mac vs Linux). Standardize on CI platform.
  • Missing Chrome on CI: shinytest2 needs Chrome/Chromium. Always include install step.

  • build-shiny-module — create testable modules w/ clear interfaces
  • scaffold-shiny-app — set up app structure w/ testing infra
  • write-testthat-tests — general testthat patterns for R pkgs
  • setup-github-actions-ci — CI/CD setup for R pkgs (golem apps)

Dépôt GitHub

pjt222/agent-almanac
Chemin: i18n/caveman-ultra/skills/test-shiny-app
0
agentsagentskillsai-assisted-developmentclaude-codeskillsteams

Compétences associées

evaluating-llms-harness

Tests

Cette compétence Claude exécute le lm-evaluation-harness pour évaluer les modèles de langage sur plus de 60 tâches académiques standardisées telles que MMLU et GSM8K. Elle est conçue pour permettre aux développeurs de comparer la qualité des modèles, de suivre les progrès de l'entraînement ou de rapporter des résultats académiques. L'outil prend en charge différents backends, incluant les modèles HuggingFace et vLLM.

Voir la compétence

cloudflare-cron-triggers

Tests

Cette compétence fournit une connaissance complète pour la mise en œuvre de Déclencheurs Cron Cloudflare afin de planifier des Workers à l'aide d'expressions cron. Elle couvre la configuration de tâches périodiques, de travaux de maintenance et de flux de travail automatisés, tout en traitant des problèmes courants tels que les expressions cron non valides et les problèmes de fuseau horaire. Les développeurs peuvent l'utiliser pour configurer des gestionnaires planifiés, tester des déclencheurs cron et intégrer avec Workflows et Green Compute.

Voir la compétence

webapp-testing

Tests

Cette Compétence Claude fournit une boîte à outils basée sur Playwright pour tester des applications web locales via des scripts Python. Elle permet la vérification frontend, le débogage d'interface utilisateur, la capture d'écrans et la consultation des journaux, tout en gérant les cycles de vie du serveur. Utilisez-la pour les tâches d'automatisation de navigateur, mais exécutez les scripts directement plutôt que de lire leur code source pour éviter la pollution du contexte.

Voir la compétence

finishing-a-development-branch

Tests

Cette compétence aide les développeurs à finaliser leur travail en vérifiant que les tests passent, puis en présentant des options d'intégration structurées. Elle guide le processus de fusion, de création de PRs ou de nettoyage des branches une fois l'implémentation terminée. Utilisez-la lorsque votre code est prêt et testé pour finaliser systématiquement le cycle de développement.

Voir la compétence