Merge #4, #6 on top of upstream master #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
This allows you to write commands whose input changes when a previous
Command shrinks.
For example, suppose the state contains `someList :: [Bool]` and
you have a command whose input expects "index into `someList` pointing
at `True`". You can generate that index directly, but if an earlier
command shrinks, `someList` might change and your index now points at
`False`.
(This is contrived, but hopefully points at the sorts of more
complicated situations where it might be useful.)
With this you can instead generate a number between 0 and (the number of
`True` elements). Then use `mkInput` to turn that number into an index
into `someList`. This will still be valid as long as the number of
`True` elements doesn't shrink below the generated value.
You could also pass this number directly into `exec`. But then in `exec`
you'd need to get `someList` directly from the concrete model, which
might be complicated and/or slow.
I implemented this by adding a new `Command` constructor, `CommandA`
where A is for Advanced. I don't love this. I could have simply changed
the existing constructor, but that means every existing Command needs to
be updated. (It's a simple change, `commandMkInput = const Just` means
they work as before, but still a massive pain.) The downside of this
approach is implementation complexity, plus any user functions taking a
`Command` as input may need to be updated.
Other approaches we could take here:
1. We could pass the concrete state into `exec` along with the concrete
input. Then you wouldn't need to get `someList` from the model. But you
might still need to do complicated calculations in `exec` which could
make the failure output hard to follow.
If we did this we'd have the same tradeoff between changing the
existing constructor and adding a new one.
2. We could add a callback
```haskell
MapMaybeInput
(state Symbolic -> input Symbolic -> Maybe (input Symbolic)
```
Each of these would be applied in turn to update the input.
(`Require` would be equivalent to a `MapMaybeInput` that ignores
state, and either returns the input unchanged or `Nothing`.)
This would be compatible with existing commands, but functions
accepting a `Command` or a `Callback` as input might still need
changing.
We don't need `actionInput0`, because it was only used to pass to `actionRefreshInput`. So we can just hide it in a closure.
Rebase #3 on master
It's not useful with `recheckAt`, and makes fast growth more awkward to implement. This might break compatibility more than upstream wants, but at this point I've mostly given up on getting things merged there. If they do want fast growth we can figure out something.
Closes hedgehogqa#472. We now grow test size in fixed increments from 0 to 99, or as close as we can without going over, in however many tests we run. If we run more than n * 100 tests, then we go from 0 to 99 n times, and then do fixed increments for the remainder. Additionally, if we discard a bunch of times in a row we start to grow the size.
They're ignored, but this means hspec-hedgohog works again. Also, there was a parameter named `size` that should have been named `seed`.
Grow size faster with a small number of tests
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.
The way I currently plan to manage history is:
masterof this repo pointed at (or behind)masterof upstreammaster(use dates for versioning)So the last branch was proda-202212, which was "upstream master from december 2022, plus some local changes". This branch is proda-202312, which is currently "upstream master from april 2023", and will soon be "...plus some local changes". Next time we bring in upstream changes, we'll branch again and merge this branch into that.
For now I'm merging. If any local changes get accepted upstream it may be that a rebase will be simpler, especially if what gets accepted is different than what we have here.
The local changes we currently have that aren't in master are #4 and #6.