It's easy to forget to document and export a new function. Using testthat for your test suite makes it even easier to forget because it evaluates your test code inside the package's namespace, so internal, non-exported functions can be accessed. So you might write a new function, get passing tests, and then tell your package users about the function, but when they try to run it, they get Error: object 'coolNewFunction' not found.

public(...)

Arguments

... Code to evaluate

Value

The result of ... evaluated in the global environment (and not the package environment).

Details

Wrap public() around test blocks to assert that the functions they call are exported (and thus fail if you haven't documented them with @export or otherwise added them to your package NAMESPACE file).

An alternative way to test that your functions are exported from the package namespace is with examples in the documentation, which R CMD check runs in the global namespace and would thus fail if the functions aren't exported. However, code that calls remote APIs, potentially requiring specific server state and authentication, may not be viable to run in examples in R CMD check. public() provides a solution that works for these cases because you can test your namespace exports in the same place where you are testing the code with API mocks or other safe testing contexts.