TestHarness should be able to start directory walking in another directory #14599
Labels
C: TestHarness
Good first issue
P: normal
A defect affecting operation with a low possibility of significantly affects.
T: task
An enhancement to the software.
Reason
Some of our applications have the need to check in very large mesh files or other data files for running examples or problems. It makes sense to split these out into a separate repository so that our source repositories don't grow too large. The problem with doing this now is the TestHarness will not search for tests in submodules and other solutions where you use relative paths to find the TestHarness from the destination directory are a bit clunky. There are several ways to test in submodules but we need better support in the TestHarness.
Design
I can think of at least three possible designs to make this work:
Add an option to the TestHarness (maybe -C
) that will change to the directory before starting the walk. In this case, we wouldn't check the directory to make sure we aren't crossing git repository boundaries.Allow the TestHarness to search up from the current directory until it finds the designated application. We already do this for finding testroot. This might be a good feature anyway. Of course this would probably mean that we'd need to have a somewhat orphaned run_tests script sitting in these separate submodules. This isn't necessarily a bad idea because it would give users of these submodules a natural way to test them since the script would be right in the root.
All users to override the "don't test in submodules" behavior in the TestHarness. As a global option this isn't something we want. The TestHarness would find moose_test tests, module tests and other things that most likely won't run under other application binaries. However, if we had a allow testing in a specific submodule, that would make running all the tests together really handy (e.g. run both the integration tests and the heavier examples in a single invocation).
It might turn out that the best path forward is to implement a few of these designs. They are somewhat complementary to one and other. I think my vote would be to implement at least 1 and 3, but we might want 2 eventually.
Impact
New features that simplify testing of separate tests located in a different submodule.
The text was updated successfully, but these errors were encountered: