Repository navigation
Add functionality for varying optimization level directly into test() #5429
Description
Activity
Agree. One thing is that we test verbose output for specific strings to ensure optimization is on or off when we think it should be. Maybe just a tweak to test() would overcome that. Plus moving the 2 or 3 relatively longer running sections into benchmark.Rraw. Those could be left in test.Rraw with a reduced size so they're still tested for correctness. Nothing else springs to mind. It's at under 1 minute so doubling that should be ok on CRAN.
we should be able to accomplish this with key-value pairs of optimization level-expected output.
Also it would be nice if verbose=TRUE was automatically set by test() if output= was provided so we don't have to add verbose= into each query. On the other hand sometimes we check that printed output is correct not the verbose output. Maybe adding verbose= argument to test() then. Seeing the string passed to verbose= should be clear the intention of checking the verbose output contains that string and not that we want verbose output from test() for some reason.
Related to #4305
Subsumed by #5842
We have a lot of code in tests that does rigamarole around tests for different optimization levels. we should take a look at how to consolidate this into the signature of test(), if possible.
test(optimization_levels = c(...)) looks like the simplest signature, but not sure it's general enough to capture what varies by level. Needs more investigation.