dryrun: keep track of loop variables from parent testsets #28
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
Partially fixes #27. The full fix might be to make `resolve!` also keep track of these loop variables; but this would involve storing lists of collected iterators for each nested testset: once we evaluate an iterator for filtering in `resolve!`, we have to store it in case it has some random behavior (e.g. `rand(1:9, i)` where `i` is a loop variable from a parent testset), in which case re-evaling it at execution time would lead to inconsistency. The testset tree would also have to be traversed depth-first by also unfolding testset-for. This could be a nice improvement if the perfs don't suffer (instead of storing parent strings subjects and looping through them, we would store iterators and recurse into them).
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.
Partially fixes #27.
The full fix might be to make
resolve!also keep track of theseloop variables; but this would involve storing lists of collected
iterators for each nested testset: once we evaluate an iterator
for filtering in
resolve!, we have to store it in caseit has some random behavior (e.g.
rand(1:9, i)whereiisa loop variable from a parent testset), in which case re-evaling
it at execution time would lead to inconsistency.
The testset tree would also have to be traversed depth-first by also
unfolding testset-for. This could be a nice improvement if the perfs
don't suffer (instead of storing parent strings subjects and looping
through them, we would store iterators and recurse into them).