Feature request: Add recursive search for test files

[gdurif]

Hi,
a great feature would be to add recursive search on the directory test/testthat (e.g. when calling testthat::test_dir like in devtools::test or devtools::check), so that it would be possible to organize the test directory properly and make its structure correspond to the R source file organization in the R directory (where you can put sub-directories by using the Collate: field in the DESCRIPTION file).

Thanks in advance

[jimhester]

Personally I don't think the added complexity of this is worthwhile. According to Writing R Extensions the only acceptable subdirectories are 'unix' and 'windows' for platform specific code.

The R and man subdirectories may contain OS-specific subdirectories named unix or windows.
And this also seems to be true in limited testing.

I think in general there are better ways to have OS specific code then relying on this feature.

[gdurif]

The issue is that, when you have very rich package with a lots of functions and R source files, the policy about having no sub-directories in R folder is quite limiting and does not allow any organisation of the source files, which facilitate the development.
Anyway, thanks for your answer
Best

[DDorch]

I'm sorry @jimhester but I think you didn't get the point (or I didn't understand your answer).

@gdurif asked for the ability to recursively search test files into test/testthat directory such as in this example: https://stackoverflow.com/questions/48991329/is-there-a-way-to-make-testthat-search-recursively

This could be simply done by adding a recursive=TRUE at the call of dir in find_test_scripts function.

[gdurif]

Thanks for the reformulation @DDorch, it is exactly what I maint. I should not have mentioned the R source directory since it is a different and independent issue.

[MichaelChirico]

r-lib/styler#1105 (comment)

provides an example of why this can be practically pretty important.

we'd like to split up a test file into a dozen or so "child" files to get better performance in parallel. this will pollute the testthat/ directory...

somehow allowing nesting seems to me a much more natural solution.

alternatively, offering a more flexible API in test_check() would allow a lateral approach here by adding those tests to be run by a different driver in tests/ while still using essentially the same basic testthat machinery, just referring to a different child directory than tests/testthat.