auto_test_package: propagate filter argument to test_dir()

[torbjorn]

It would be nice to work with only a subset of test files with auto_test_package.

There are some test scripts that take a long time, others are fast.

If I work with a faster script, it'd be a bummer to have to wait for those longer, not so interesting at the moment, test files.

it looks like it can be solved by simply allowing auto_test_package() to have a filter=NULL argument and pass that to test_dir further down.

[hadley]

auto_test_package() is basically retired; we don't use it anymore and don't plan to add any more features to it.

[torbjorn]

I see. Is there any other watch-like mechanic in testthat that I should use instead or is the concept retired too?

[torbjorn]

Sorry for whipping this dead horse, but isn't anyone auto running tests as they write code like this? I find it an awesome way to develop. No need to alt-tab somewhere else to run tests, or hit key combos to run them. Just save the buffer and watch the tests run.

[chris-perts]

I agree with the OP.

The current documented testing workflow is:

1. Modify your code or tests.
2. Test your package with Ctrl/Cmd + Shift + T or devtools::test().
3. Repeat until all tests pass.

While the workflow before auto_test was broken (see #1385) omitted an entire step:

1. Modify your code or tests.
2. Repeat until all tests pass.

From my experience with other ecosystems, having a hot-reloading test runner open while you develop is standard practice.

I propose:

• The functionality of auto_test be restored.
• The workflow documentation be modified to describe auto_test running in a separate window as standard practice (or at least a strong alternative).

Would r-lib be open to a PR on this matter?

[hadley]

Yeah, a PR would be great.