testexec: subtest ("then-*") feature #7
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Not yet tested.
…then-subtest feature. One small fix, which makes sure it's fine for subtests to not continue to add files using the file fixture mechanism, which previously threw an NPE (whoopsie).
|
Added self-test. Almost got a hole-in-one... but one nil pointer fix was needed. So close. Works now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With this feature, naming a hunk in the pattern of
{testname}/then-{subtestname}/script(when there's already a{testname}/scripthunk, so testexec is already in motion) will cause subtests to run.Subtests are more of the same, but have one especially useful feature: they start within a working directory that's a copy of the files and directories that were in the working directory of the parent test after it was finished.
Subtests can be nested --
{testname}/then-{subtestname}/then-{subsubtestname}/script-- in which case each of them continues getting a copy of the filesystem from the test that came before them....... or, subtests can fan out --
{testname}/then-{subtestname}/scriptand{testname}/then-{othersubtestname}/script-- in which case each of them gets a copy of the parent, but separate copies, which do not interfere with each other.This should help a great deal in writing tests for programs that have filesystem state. It can also be very useful for writing suites of tests for a program that needs some configuration files, and you don't want to repeat those every time: now you can just use the top level test to set up the config files, and then use a bunch of sibling subtests for all the actual testing work.
(This is itself... not yet tested. Don't rely on this commit hash; this PR may be rebased.)