Suggestion: Support for multiple expectations per test#1
Draft
wldmr wants to merge 3 commits intobattila7:masterfrom
Draft
Suggestion: Support for multiple expectations per test#1wldmr wants to merge 3 commits intobattila7:masterfrom
wldmr wants to merge 3 commits intobattila7:masterfrom
Conversation
Saves us the parallel indexing and `.unwrap()`.
… to get around ownership issues. Turns out that by lugging around the lifetimes of the constituent `ExpectationChain`s we failed to compile when using the `.here()` method on non-`Copy` types, because those references don’t outlive the `.here()` call. (Who could have guessed? …) The solution: We conclude the expectation chain there and then, and we only keep the error messages around. Makes the code much simpler, too.
This file contains hidden or 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
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.
Being a fan of simple libraries, I was drawn to yours. Great work!
However, when I found myself wanting to check the contents of a HashMap, I found it difficult to compose expectations (which is a general problem with fluent assertions, it seems).
So I came up with this: There's a container for multiple expectation chains. You gradually add them, and at the end you call
conclude_*()as you would on a single chain.For a HashMap of Bitflags (my usecase) this would look something like
There's also a way to modify multiple expectations non-fluently. The above checks would then look something like this:
This is mainly meant for cases where you want to ensure certain intermediate results before the "big one" at the end.
What do you think? Would composition be something you'd find useful for this library? I'm happy to discuss and tweak things, of course. But I thought I'd start with a concrete suggestion and not just by opening an issue with a vague request.