R Packages, 2nd Edition

Chapter 14. Designing Your Test Suite

This chapter runs a few small bits of testthat code, so we must do some setup that is not necessary in organic testthat usage.

Warning

Your test files should not include these library() calls. We also explicitly request testthat edition 3, but in a real package this will be declared in DESCRIPTION:

library(testthat)
local_edition(3)

What to Test

Whenever you are tempted to type something into a print statement or a debugger expression, write it as a test instead. — Martin Fowler

There is a fine balance to writing tests. Each test that you write makes your code less likely to change inadvertently; but it also can make it harder to change your code on purpose. It’s hard to give good general advice about writing tests, but you might find these points helpful:

• Focus on testing the external interface to your functions—if you test the internal interface, then it’s harder to change the implementation in the future because as well as modifying the code, you’ll also need to update all the tests.

• Strive to test each behavior in one and only one test. Then if that behavior later changes you need to update only a single test.

• Avoid testing simple code that you’re confident will work. Instead focus your time on code that you’re not sure about, is fragile, or has complicated interdependencies. That said, we often find we make the most mistakes when we falsely assume that the problem is simple and doesn’t need any tests.

• Always write a test ...