CODEWITHSUNDEEP
rdata.tabletestthat
mjv
mjv

Reputation: 75125

Simple data.table snippet fails when run in testthat unit test

I get errors when running devtools::test() with the single test file, shown below. Yet, when running thetest_that statement on its own (or the code within, line-by-line), it works perfectly, i.e. myDt1 has one column (y) and myDt has two columns (x and z), the expect_equal statements are satisfied, no fail, no run time error...

Surely, I must be doing something wrong, but I can't see the obvious! This seems related to the features of data.table which rely on NSE (Non-Standard Evaluation), tentatively conflicting with some of the NSE and other magic which testthat uses?

Help!

context("data.table and testthat do not play nice ?")
library(data.table)

test_that("data.table ", {

  # the following runs perfectly on it own
  # but fails when run as a test.
  myDt <- data.table(x=rnorm(10), y=rnorm(10), z=rnorm(10))
  targetCols <- c("y")

  myDt1 <- myDt[, targetCols, with=FALSE]
  expect_equal(ncol(myDt1), 1)

  myDt2 <- myDt[, !targetCols, with=FALSE]
  expect_equal(ncol(myDt2), 2)
})

The errors I get when in test mode are: The "1. Failure" is due to the fact myDt1 didn't get created, it is NULL, without producing an error. The "2. Error" indicates that the !targetCols doesn't get interpreted properly. Neither of these happen when run outside of the devtool::test() framework.

> devtools::test()
Loading myLib
Testing myLib
data.table and testthat do not play nice ?: 12

Failed -----------------------------
1. Failure: data.table  (@testSimple.R#9) ----------------
ncol(myDt1) not equal to 1.
target is NULL, current is numeric


2. Error: data.table  (@testSimple.R#11) -----------------
invalid argument type
1: myDt[, !targetCols, with = FALSE] at D:\GitRepos\BlueMoon/tests/testthat/testSimple.R:11
2: `[.data.table`(myDt, , !targetCols, with = FALSE) at D:\GitRepos\BlueMoon/tests/testthat/testSimple.R:11
3: `[.data.frame`(x, i, j)

DONE ========================================================================
>

Upvotes: 1

Views: 222

Answers (1)

mjv
mjv

Reputation: 75125

Problem solved: There was no import(data.table) command in the NAMESPACE file. Adding it solved the issue. In my case, I added it indirectly, since I use roxygen, i.e. with 

#' @import data.table
NULL

in one -or several- of the source files. Here, commenting a NULL object, but that could also be any one of the function which uses the data.table library. (When said usage is pervasive, there's no real benefit to adding these in a way that tracks all functions that use the package).

Upvotes: 1

Related Questions