Address races when using Returns and ReturnsOnCall, and make the behavior of ReturnsOnCall be less annoying. #84
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.
Although there is an RWMutex in the mocking structure, it is used inconsistently, leading to the Go race detector to cause sporadic data race errors while unit testing.
The ...ReturnsOnCall() method allows for the creation of a map such that one may specify return values on arbitrary calls to the mocked function. For example, you can request that the first two invocations fail, followed by a successful call, in order to check out retry behavior. The problem is that once this map is set, the default return value for the mocked function call becomes all nils and not what was intended. This led to situations where it was necessary to call the mocked function first and save the returns, then set the map values for failures to one offset from the desired index, and set ANY indices that might be hit other to the saved default value. This violates the Principle of Least Surprise.