testthat is a unit testing framework for R that makes it easy to write and run tests for your code. It provides functions to define expectations, capture errors and warnings, and integrates with standard R package development workflows.
The package offers visual progress reporting with colored output, integrates seamlessly into both informal command-line testing and formal R CMD check processes, and draws from established testing frameworks like xUnit and rspec. It’s the most widely-used testing package in the R ecosystem, adopted by thousands of CRAN packages. The framework is designed to make testing straightforward enough that it becomes a regular part of development rather than an afterthought.
Contributors#
Resources featuring testthat#
Claude Code for R | Hadley Wickham
Talk from rainbowR conference 2026: https://conference.rainbowr.org
If youāve been paying attention to software engineering social media lately, you might have noticed a lot of noise about Claude Code and the Opus 4.5 model. For me personally, these have pushed AI coding assistance from a ānice to haveā to something that feels just as important as git.
In this talk, Iāll show you a couple of my āvibeā coded experiments, but more importantly show you how Claude Code helps me write higher-quality R code faster. Iāve used it a bunch recently for both testthat and dbplyr, two large, well-established code bases where quality is more important than velocity
Birthing the pregnancy package (Ella Kaye, University of Warwick) | posit::conf(2025)
Birthing the pregnancy package
Speaker(s): Ella Kaye
Abstract: When I was pregnant, I wrote a personal, private package for date and medication calculations, hard-coded with my data. I thought it would be easy to adapt for general use, but no! I wanted the user experience to be excellent, but how to avoid them repeatedly entering the same due date and meds? How to print useful, nicely formatted, grammatically correct information to the console? How to test a package that relies on the current date? Using the pregnancy package as a case study, I’ll show how to take advantage of base R features such as global options and %||%, how the cli and rlang packages came to the rescue for messages and how testthat’s new mocking features saved the day (literally!) to create a package that’s a pleasure to use.
Slides: https://github.com/EllaKaye/pregnancy-lightning-talk posit::conf(2025) Subscribe to posit::conf updates: https://posit.co/about/subscription-management/
How non-programmers can make sparks fly when using testthat during package development (L. McKenna)
Enemies to lovers: How non-programmers can make sparks fly when using testthat during package development
Speaker(s): Libby McKenna
Abstract:
Youāre just a data scientist, self-taught in R, trying to find your way in the world of package development. Itās just a package named testthat, hoping to help a developer make sure their package is operating as intended. You meet. You hate each other. The package seems a little daunting and quite frankly, a little tedious. Surely only ārealā programmers use this! The package thinks youāre inept for not immediately putting it to use. As fate would have it, you attend this talk and discover you are indeed compatible. Sparks fly, a package is born. This talk will help less experienced programmers learn about testing, automated workflows, how to write good tests, and why itās all worth it when it pays off in quality and efficiency. Steamy. posit::conf(2025) Subscribe to posit::conf updates: https://posit.co/about/subscription-management/
Hadley Wickham - R in Production
R in Production by Hadley Wickham
Visit https://rstats.ai for information on upcoming conferences.
Abstract: In this talk, we delve into the strategic deployment of R in production environments, guided by three core principles to elevate your work from individual exploration to scalable, collaborative data science. The essence of putting R into production lies not just in executing code but in crafting solutions that are robust, repeatable, and collaborative, guided by three key principles:
-
Not just once: Successful data science projects are not a one-off, but will be run repeatedly for months or years. I’ll discuss some of the challenges for creating R scripts and applications that run repeatedly, handle new data seamlessly, and adapt to evolving analytical requirements without constant manual intervention. This principle ensures your analyses are enduring assets not throw away toys.
-
Not just my computer: the transition from development on your laptop (usually windows or mac) to a production environment (usually linux) introduces a number of challenges. Here, I’ll discuss some strategies for making R code portable, how you can minimise pain when something inevitably goes wrong, and few unresolved auth challenges that we’re currently working on.
-
Not just me: R is not just a tool for individual analysts but a platform for collaboration. I’ll cover some of the best practices for writing readable, understandable code, and how you might go about sharing that code with your colleagues. This principle underscores the importance of building R projects that are accessible, editable, and usable by others, fostering a culture of collaboration and knowledge sharing.
By adhering to these principles, we pave the way for R to be a powerful tool not just for individual analyses but as a cornerstone of enterprise-level data science solutions. Join me to explore how to harness the full potential of R in production, creating workflows that are robust, portable, and collaborative.
Bio: Hadley is Chief Scientist at Posit PBC, winner of the 2019 COPSS award, and a member of the R Foundation. He builds tools (both computational and cognitive) to make data science easier, faster, and more fun. His work includes packages for data science (like the tidyverse, which includes ggplot2, dplyr, and tidyr)and principled software development (e.g. roxygen2, testthat, and pkgdown). He is also a writer, educator, and speaker promoting the use of R for data science. Learn more on his website, http://hadley.nz .
Mastodon: https://fosstodon.org/@hadleywickham
Presented at the 2024 New York R Conference (May 17, 2024) Hosted by Lander Analytics (https://landeranalytics.com )
posit::conf(2023) Workshop: Fundamentals of Package Development
Register now: http://pos.it/conf Instructor: Andy Teucher Workshop Duration: 1-Day Workshop
This workshop is for you if: ā¢ You have written several R scripts and find yourself wondering how to reuse or share the code youāve written ā¢ You know how to write functions in R ā¢ You are looking for a way to take the next step in your R programming journey
We will be demonstrating some workflows using Git and GitHub. Knowledge of these tools is not required, and you will absolutely be able to complete the workshop without them, but some of the lessons will be more rewarding to you if you are prepared to try them out. If you are looking to get started with Git and GitHub, we recommend you register for the āWhat they forgot to teach you about Rā workshop on Day 1, and join us for this workshop on Day 2.
We are often faced with the need to share our code with others, or find ourselves writing similar code over and over again across different projects. In R, the fundamental unit of reusable code is a package, containing helpful functions, documentation, and sometimes sample data. This workshop will teach you the fundamentals of package development in R, using tools and principles developed and used extensively by the tidyverse team - specifically the ādevtoolsā family of packages including usethis, testthat, and roxygen2. These packages and workflows help you focus on the contents of your package rather than the minutiae of package structure.
You will learn the structure of a package, how to organize your code, and workflows to help you develop your package iteratively. You will learn how to write good documentation so that users can learn how to use your package, and how to use automated testing to ensure it is functioning the way you expect it to, now and into the future. You will also learn how to check your package for common problems, and how to distribute your package for others to use.
This will be an interactive 1-day workshop, and we will be using the RStudio IDE to work through the materials, as it has been designed to work well with the development practices we will be featuring
Barret Schloerke | {shinytest2}: Unit testing for Shiny applications | RStudio (2022)
Manually testing Shiny applications is often laborious, inconsistent, and doesnāt scale well. Whether you are developing new features, fixing bug(s), or simply upgrading dependencies, it is critical to know when regressions are introduced. The new {shinytest2} R package provides a toolkit for unit testing Shiny apps and seamlessly integrates with {testthat}. Under the hood, it uses the new {chromote} R package to render apps in a headless Chrome browser with features such as live preview and built in debugging tools. In this talk, youāll learn how to test Shiny apps by simply recording your actions as code and extending it to test more particular aspects of your app, resulting in fewer bugs and more confidence in future development.
Talk materials are available at https://bit.ly/shinytest2-conf22
Session: I like big apps: Shiny apps that scale
Getting Started with {shinytest2} Part 2 || Exporting values || RStudio
00:00 Introduction 00:29 Exporting reactives 03:28 Using exportTestValues()
Part 1 - Getting started: https://youtu.be/SS1Na3c8lhk Part 3 - Using shiny.testmode: https://youtu.be/xDxa_mDwN04
Manually testing Shiny applications is often laborious, inconsistent, and doesnāt scale well. Whether you are developing new features, fixing bug(s), or simply upgrading dependencies on a serious app where mistakes have real consequences, it is critical to know when regressions are introduced. shinytest2 provides a streamlined toolkit for unit testing Shiny applications and seamlessly integrates with the popular testthat framework for unit testing R code.
shinytest2 uses chromote to render applications in a headless Chrome browser. chromote allows for a live preview, better debugging tools, and/or simply using modern JavaScript/CSS.
By simply recording your actions as code and extending them to test the more particular aspects of your application, it will result in fewer bugs and more confidence in future Shiny application development.
Read up on shinytest2 here: https://rstudio.github.io/shinytest2/
Learn more about Shiny here: https://shiny.rstudio.com/
Got questions? The RStudio Community site is a great place to get assistance: https://community.rstudio.com/
Content: Barret Schloerke (@schloerke) Motion design and editing: Jesse Mostipak (@kierisi)
Theme song: Brad PKL by Blue Dot Sessions (https://app.sessions.blue/browse/track/113507 )
Getting Started with {shinytest2} Part 3 || Using shiny.testmode in {shinytest2} || RStudio
00:00 Introduction 00:15 Testing production apps
Part 1 - Getting started: https://youtu.be/SS1Na3c8lhk Part 2 - Exporting values: https://youtu.be/7KLv6HdIxvU
Manually testing Shiny applications is often laborious, inconsistent, and doesnāt scale well. Whether you are developing new features, fixing bug(s), or simply upgrading dependencies on a serious app where mistakes have real consequences, it is critical to know when regressions are introduced. shinytest2 provides a streamlined toolkit for unit testing Shiny applications and seamlessly integrates with the popular testthat framework for unit testing R code.
shinytest2 uses chromote to render applications in a headless Chrome browser. chromote allows for a live preview, better debugging tools, and/or simply using modern JavaScript/CSS.
By simply recording your actions as code and extending them to test the more particular aspects of your application, it will result in fewer bugs and more confidence in future Shiny application development.
Read up on shinytest2 here: https://rstudio.github.io/shinytest2/
Learn more about Shiny here: https://shiny.rstudio.com/
Got questions? The RStudio Community site is a great place to get assistance: https://community.rstudio.com/
Content: Barret Schloerke (@schloerke) Motion design and editing: Jesse Mostipak (@kierisi)
Theme song: Brad PKL by Blue Dot Sessions (https://app.sessions.blue/browse/track/113507 )
Getting Started with {shinytest2} Part I || Example + basics || RStudio
00:00 Introduction 00:48 Overview of the demo Shiny app 03:00 Running record_test() 04:44 Results from record_test() 07:18 A note on .png files created during testing 08:52 Debugging with shinytest2 09:32 Using app$view() to open a visual representation of a headless browser
Part 2 - Exporting values: https://youtu.be/7KLv6HdIxvU Part 3 - Using shiny.testmode: https://youtu.be/xDxa_mDwN04
Manually testing Shiny applications is often laborious, inconsistent, and doesnāt scale well. Whether you are developing new features, fixing bug(s), or simply upgrading dependencies on a serious app where mistakes have real consequences, it is critical to know when regressions are introduced. shinytest2 provides a streamlined toolkit for unit testing Shiny applications and seamlessly integrates with the popular testthat framework for unit testing R code.
shinytest2 uses chromote to render applications in a headless Chrome browser. chromote allows for a live preview, better debugging tools, and/or simply using modern JavaScript/CSS.
By simply recording your actions as code and extending them to test the more particular aspects of your application, it will result in fewer bugs and more confidence in future Shiny application development.
Read up on shinytest2 here: https://rstudio.github.io/shinytest2/
Learn more about Shiny here: https://shiny.rstudio.com/
Got questions? The RStudio Community site is a great place to get assistance: https://community.rstudio.com/
Content: Barret Schloerke (@schloerke) Motion design and editing: Jesse Mostipak (@kierisi)
Theme song: Brad PKL by Blue Dot Sessions (https://app.sessions.blue/browse/track/113507 )
Hadley Wickham | testthat 3.0.0 | RStudio (2020)
In this webinar, I’ll introduce some of the major changes coming in testthat 3.0.0. The biggest new idea in testthat 3.0.0 is the idea of an edition. You must deliberately choose to use the 3rd edition, which allows us to make breaking changes without breaking old packages. testthat 3e deprecates a number of older functions that we no longer believe are a good idea, and tweaks the behaviour of expect_equal() and expect_identical() to give considerably more informative output (using the new waldo package).
testthat 3e also introduces the idea of snapshot tests which record expected value in external files, rather than in code. This makes them particularly well suited to testing user output and complex objects. I’ll show off the main advantages of snapshot testing, and why it’s better than our previous approaches of verify_output() and expect_known_output().
Finally, I’ll go over a bunch of smaller quality-of-life improvements, including tweaks to test reporting and improvements to expect_error(), expect_warning() and expect_message().
Webinar materials: https://rstudio.com/resources/webinars/testthat-3/
About Hadley: Hadley Wickham is the Chief Scientist at RStudio, a member of the R Foundation, and Adjunct Professor at Stanford University and the University of Auckland. He builds tools (both computational and cognitive) to make data science easier, faster, and more fun. You may be familiar with his packages for data science (the tidyverse: including ggplot2, dplyr, tidyr, purrr, and readr) and principled software development (roxygen2, testthat, devtools, pkgdown). Much of the material for the course is drawn from two of his existing books, Advanced R and R Packages, but the course also includes a lot of new material that will eventually become a book called “Tidy tools”
Karl Broman | R qtl2 Rewrite of a very old R package | RStudio (2019)
For nearly 20 years, I’ve been developing, maintaining, and supporting an R package, R/qtl, for mapping quantitative trait loci (genetic loci that contribute to variation in quantitative traits, such as blood pressure) in experimental crosses (such as in mice). It’s a rather large package, with 39k lines of R code, 24k lines of C code, and nearly 300 user-accessible functions. In the past several years, I’ve been working on rewriting the package, to better handle high-dimensional data and more complex experimental crosses. This has been a good opportunity to take advantage of many new tools, including Rcpp, Roxygen2, and testthat. I’ll describe my efforts to avoid repeating the mistakes I made the first time around.
VIEW MATERIALS https://bit.ly/rstudio2019
About the Author Karl Broman Karl Broman is Professor in the Department of Biostatistics & Medical Informatics at the University of WisconsināMadison; research in statistical genetics; developer of R/qtl (for R). Karl received a BS in mathematics in 1991, from the University of WisconsināMilwaukee, and a PhD in statistics in 1997, from the University of California, Berkeley; his PhD advisor was Terry Speed. He was a postdoctoral fellow with James Weber at the Marshfield Clinic Research Foundation, 1997ā1999. He was a faculty member in the Department of Biostatistics at Johns Hopkins University, 1999ā2007. In 2007, he moved to the University of WisconsināMadison, where he is now Professor. Karl is a Senior Editor for Genetics, Academic Editor for PeerJ, and a member of the BMC Biology Editorial Board. Karl is an applied statistician focusing on problems in genetics and genomics ā particularly the analysis of meiotic recombination and the genetic dissection of complex traits in experimental organisms. The latter is often called āQTL mapping.ā A QTL is a quantitative trait locus ā a genetic locus that influences a quantitative trait. Recently he has been focusing on the development of interactive data visualizations for high-dimensional genetic data; see his R/qtlcharts package and his D3 examples
