Interaction between parallel testing and `browser()`

[lionel-]

When parallel testing is enabled, tests return early when hitting browser().

[hadley]

Do you think there's anything we can do here? Obviously parallel tests are run in a separate process.

[lionel-]

Could we shim browser() to throw an informative message to the user? Currently the test suite seems to stop entirely without information.

[hadley]

Hmmm, maybe browser <- function() skip("browser() called in non-interactive context") when is_interactive() is FALSE?

[lionel-]

oh yes skip()ing is good idea.

[lionel-]

Also debug() and debugonce() I guess.

The message should mention how to disable parallel tests for debugging sessions. Do we have an easy switch?

[hadley]

I usually just switch to test_file() which runs in-process for me (I usually activate devtools::test() with the RStudio keyboard shortcut so it runs in a separate process in the build pane).

[scottkosty]

test_file() seems to work well with browser(). There are two minor inconveniences of this workflow: (1) you have to specify the file name to test_file(), and (2) I found I had to load my package under development, i.e., I had to manually run devtools::load_all("~/mypackage").

Would it be reasonable to disable parallelization if Ncpus is set to 1? I think a fast workflow would be to have parallelization enabled by default and then when I want to drop into browser I can just run options(Ncpus = 1); devtools::test().

[hadley]

This is now resolved because we set _R_CHECK_BROWSER_NONINTERACTIVE_. (It's not perfect but I think it's all you need to discover there's a browser sitting around)