# Example of unit testing R code with testthat

Here’s a little example of using Hadley Wickham’s `testthat` package for unit testing R code. You can read more about `testthat` here.

The function below computes the real roots of a quadratic. All that really matters for our purposes is that the function can return 0, 1, or 2 numbers and it could raise an error.

```real.roots <- function(a, b, c)
{
if (a == 0.)

d = b*b - 4*a*c # discriminant

if (d < 0)
rr = c()
else if (d == 0)
rr = c( -b/(2*a) )
else
rr = c( (-b - sqrt(d))/(2*a),
(-b + sqrt(d))/(2*a)  )

return(rr)
}```

To test this code with `testthat` we create another file for tests. The name of the file should begin with `test` so that `testthat` can recognize it as a file of test code. So let name the file containing the code above `real_roots.R` and the file containing its tests `test_real_roots.R`.

The test file needs to read in the file being tested.

`source("real_roots.R")`

Now let’s write some tests for the case of a quadratic with two real roots.

```test_that("Distinct roots", {

roots <- real.roots(1, 7, 12)

expect_that( roots, is_a("numeric") )
expect_that( length(roots), equals(2) )
expect_that( roots < roots, is_true() )
})```

This tests that we get back two numbers and that they are sorted in increasing order.

Next we find the roots of (x + 3000)2 = x2 + 6000x + 9000000. We’ll test whether we get back -3000 as the only root. In general you can’t expect to get an exact answer, though in this case we do since the root is an integer. But we’ll show in the next example how to test for equality with a given tolerance.

```test_that("Repeated root", {

roots <- real.roots(1, 6000, 9000000)

expect_that( length(roots), equals(1) )

expect_that( roots, equals(-3000) )

# Test whether ABSOLUTE error is within 0.1
expect_that( roots, equals(-3000.01, tolerance  = 0.1) )

# Test whether RELATIVE error is within 0.1
# To test relative error, set 'scale' equal to expected value.
# See base R function all.equal for optional argument documentation.
expect_equal( roots, -3001, tolerance  = 0.1, scale=-3001)
})```

To show how to test code that should raise an error, we’ll find the roots of 2x + 3, which isn’t a quadratic. Notice that you can test whether any error is raised or you can test whether the error message matches a given regular expression.

```test_that("Polynomial must be quadratic", {

# Test for ANY error
expect_that( real.roots(0, 2, 3), throws_error() )

# Test specifically for an error string containing "zero"
expect_that( real.roots(0, 2, 3), throws_error("zero") )

# Test specifically for an error string containing "zero" or "Zero" using regular expression
expect_that( real.roots(0, 2, 3), throws_error("[zZ]ero") )
})```

Finally, here are a couple tests that shouldn’t pass.

```test_that("Bogus tests", {

x <- c(1, 2, 3)

expect_that( length(x), equals(2.7) )
expect_that( x, is_a("data.frame") )
})```

To run the tests, you can run `test_dir` or `test_file`. If you are at the R command line and your working directory is the directory containing the two files above, you could run the tests with `test_dir(".")`. In this case we have only one file of test code, but if we had more test files `test_dir` would find them, provided the file names begin with `test`.

* * *

## 4 thoughts on “Example of unit testing R code with testthat”

1. Stephen

I’m confused are you trying to demonstrate the sort of ambiguity that might lead to error by using

if d<0
rr = c()
etc
return(rr)

…whilst c() is globally a valid R command but here would seem to return NULL? Why not rr =NULL or better still never use c as a function argument?

2. I’m not saying that the code being tested is good code. That’s why I said “All that really matters for our purposes is that the function can return 0, 1, or 2 numbers and it could raise an error.”

The `real.roots` code could also have numerical precision problems if `b` is very large relative to `ac`.

3. Henrik

@Stephen, better then is to use double(0) than NULL or c() so the function always returns a “numeric”.

4. Thanks John. Examples are always easier to understand than instructions!