Expected calls matching several actual calls - (1) Preparation #1020
Conversation
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
…s that can match many actual calls (i.e. range of calls). The changes are for now just semantic: The nomenclature of "expectation fulfillment"-related methods has been changed, and also some methods have been duplicated and renamed, because expected calls will soon be able to fulfill (match) more than one single actual call, and therefore some of the internal state of expected calls will be devoted to check if the expected call matches the actual call that is being processed, and other state will check if the expected call is fulfilled as a whole (i.e. it has been called/matched a minimum number of times).
…ut early when the call has already failed.
| { | ||
| call1->ignoreOtherParameters(); | ||
| list->addExpectedCall(call1); | ||
| CHECK(! list->hasFinalizedMatchingExpectations()); |
|
It seems good. Only one comment to split a test in two. THen I'll merge this as a good start! |
|
I've split the test and added some additional ones. |
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.
As discussed in PR #1018, I submit here some small refactoring changes in preparation for the next modifications.
These modifications don't change or add any functionality, they just rename some methods and attributes, and add a couple of additional methods, in preparation for the actual implementation of multi-matching expected calls.
The key concepts changed are about matching actual calls, and fulfilling expected calls.
Until now, an expected call could match a single actual call, and when this match was done, then the expected call was fulfilled, so matching and fulfilling was rather the same thing.
From now on, these two concepts will be separated: During the processing an actual call, expected calls will be able to match it under certain conditions (i.e. parameters and object match, the expected call hasn't reached the maximum number of actual calls that it can match, etc.). However, an expected call will be considered fulfilled when it has matched its minimum and its maximum number of actual calls.
This means that an expected call will be considered to be fulfilled as soon as it reaches its minimum number of matched actual calls, but that it will be able to match actual calls until it reaches its maximum.
Additionally, expected calls have another associated concept: finalized. Calls that don't ignore parameters are automatically considered to be finalized when they have matched its object and all its parameters (if they have any). However, calls that can ignore parameters are not finalized until the actual call is finalized (i.e. checkExpectations() has been called on the actual call). I think that this clarifies a bit the "...WithoutIgnoredParameters" and "...WithIgnoredParameters" methods in expected calls list, because this nomenclature was a bit confusing (does that mean that we look for calls that can ignore parameters, or that have actually ignored already some?).
Notice that the state stored in expected calls relative to "matching" will be only relevant while an actual call is being processed, but the state stored relative to "fulfilling" will be relevant during the whole life cycle of the expected call.