Testing if a function has been exported

[hongooi73]

Recently I pushed an update to one of my packages to CRAN. Before submitting, I did my usual routine of running devtools::test() and ensuring that all the tests passed. So far, no problem. However, after it was submitted (and approved), I happened to look at the package's NAMESPACE file, and realised that I had forgotten to run devtools:document() to update the list of exported functions. Because of this, a couple of functions that I had added to the package, and marked with @export directives, were not actually exported.

Is there a way of testing that functions that should be user-visible are, indeed, visible? By default testthat doesn't do this; from ?test_package:

For package tests, that environment that inherits from the package's namespace environment, so that tests can access internal functions and objects.

Hence the tests of my new functions all passed, as the testing code could see them despite not being visible to the end-user.

[gaborcsardi]

AFAICT there is no easy way to do this in testthat currently, unfortunately. I agree that it would make complete sense to run some tests (e.g. integration tests) without having access to the internals of the package.

@hadley maybe this is something to consider for 3e. We'll need to rewrite the env part anyway, to better support parallel tests.

[hadley]

I just don't think this is possible — testthat is built around the assumption that you want to test non-exported functions so we have to use the internal package namespace.

[dvg-p4]

would it be possible to have a "strict" mode where internal package functions are still accessible but only by ::: (as they would be in production)?

[hadley]

@dvg-p4 it could, but that would be antithetical to the design of testthat.

[dvg-p4]

Hmm, how so? I see the benefit of being able to test internal functions without a string of boilerplate before every call, but it would also be nice to (at least for certain tests at certain points in a release cycle) be able to run in as production-like an environment as possible. Any suggestions?

[gaborcsardi]

You can do that already, load the package from the current directory with

pkgload::load_all(export_all=FALSE)

or load the installed package with

library(<pkgname>)

and then call

testthat::test_dir("tests/production")

or

testthat::test_dir("production")

from a tests/production.R file.