Allow values in a request to be changed by the provider state#57
Closed
tucker-m wants to merge 3 commits intopact-foundation:masterfrom
Closed
Allow values in a request to be changed by the provider state#57tucker-m wants to merge 3 commits intopact-foundation:masterfrom
tucker-m wants to merge 3 commits intopact-foundation:masterfrom
Conversation
Allow values in the request to be changed by the provider state.
Ensure that strings with a provider param variable at the beginning still get parsed correctly.
Refactor find_default_values so that it doesn't have as many loops in one method. Also using three dots instead of two for ranges, so that one doesn't need to be subtracted from the last index.
Member
|
Will be revisiting this as part of pact-foundation/pact-ruby#319 it relates to the As shown in use in pact-js consumer facing DSL here Note: I need to test what happens in the rust core with the generator rule written in v2/v3 spec, as to what happens on the verification side. |
Member
|
Going to close this off now, as we now have a pull request in place for using the rust core, which includes provider state generators |
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.
This is something that we've been using internally for a few weeks, and I wanted to suggest it as feature in Pact. This has been useful for setting object IDs in URLs and authentication tokens in the headers; you might not be able to know those values until after the provider state has been set up. After searching through the various pact-foundation repositories, it looks like other people have run into similar needs.
You can create a "provider parameter" by doing:
When the test is run on the consumer side, the URL will be
/users/1/posts.On the provider side, in your provider state, you can do this:
Let's say that
user.idwasn't 1, but that it actually got assigned 2. When you runrake pact:verify, the URL will be/users/2/posts.This is also useful with authentication tokens or UUIDs, where they are randomly generated and you have no way of knowing a valid one without knowing something about the provider state beforehand.