-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update matchers page to have examples from every language #88
Comments
Good for anyone doing hacktober! Doesn't have to be all the examples, just happy to take them one at a time. |
This looks promising as a starter for 10 https://docusaurus.io/docs/markdown-features/code-blocks#multi-language-support-code-blocks Really digging what these guys are doing at the moment, came onto my radar the other day https://pusher.com/ |
Yeah those code gates look handy. From memory, they also have the ability to store a language preference, which stays with you throughout the docs. This could mean we could provide a general guide that's applicable to all languages, but have language specific code blocks to accompany them. |
Pact matching featuresMatcher types
Matcher Links
Regular ExpressionsRuby animal_service.given("an alligator named Mary exists").
upon_receiving("a request for an alligator").
with(
method: "get",
path: "/alligators/Mary",
headers: {"Accept" => "application/json"}).
will_respond_with(
status: 200,
headers: {"Content-Type" => "application/json"},
body: {
name: "Mary",
dateOfBirth: Pact.term(
generate: "02/11/2013",
matcher: /\d{2}\/\d{2}\/\d{4}/)
}) Java service {
uponReceiving('a request')
withAttributes(method: 'get', path: '/')
withBody {
name(~/\w+/, 'harry')
surname regexp(~/\w+/, 'larry')
position regexp(~/staff|contractor/, 'staff')
happy(true)
}
} Go pact.
AddInteraction().
Given("User sally exists").
UponReceiving("A request to login with user 'sally'").
WithRequest(request{
Method: "GET",
Path: term("/users/10", "/users/[0-9]+"),
}).
WillRespondWith(dsl.Response{
Status: 200,
Body: dsl.Match(model.User{}),
Headers: commonHeaders,
}) JS const { term } = pact
provider.addInteraction({
state: "Has some animals",
uponReceiving: "a request for an animal",
withRequest: {
method: "GET",
path: "/animals/1",
},
willRespondWith: {
status: 200,
headers: {
"Content-Type": "application/json; charset=utf-8",
},
body: {
id: 100,
name: "billy",
gender: term({
matcher: "F|M",
generate: "F",
}),
},
},
}) C++ this.pact
.UponReceiving("a request to retrieve all events")
.WithRequest(HttpMethod.Get, "/events")
.WithHeader("Accept", "application/json")
.WillRespond()
.WithStatus(HttpStatusCode.OK)
.WithHeader("Content-Type", "application/json; charset=utf-8")
.WithJsonBody(Match.MinType(new
{
eventId = Match.Type("3E83A96B-2A0C-49B1-9959-26DF23F83AEB"),
timestamp = Match.Type("2014-06-30T01:38:00.8518952"),
eventType = Match.Regex("SearchView", "SearchView|DetailsView")
}, 1)); python from pact import Term
...
body = {
'username': 'UserA',
'last_modified': Term('\d+-\d+-\d+T\d+:\d+:\d+', '2016-12-15T20:16:01')
}
(pact
.given('UserA exists and is not an administrator')
.upon_receiving('a request for UserA')
.with_request('get', '/users/UserA/info')
.will_respond_with(200, body=body)) |
Ruby regex backslash escaping causing js pain again https://pact-foundation.slack.com/archives/C9VBGLUM9/p1651866363050989 |
This introduces pact.Format.iso_8601_datetime() method to match a string for a full ISO 8601 Date. This method differs does not do any sort of date validation, only checks if the string is according to the ISO 8601 spec. This method differs from `pact.Format.timestamp`, `~pact.Format.date` and `pact.Format.time` implementations in that it is more stringent and tests the string for exact match to the ISO 8601 dates format. Without `with_millis` parameter will match string containing ISO 8601 formatted dates as stated bellow: * 2016-12-15T20:16:01 * 2010-05-01T01:14:31.876 * 2016-05-24T15:54:14.00000Z * 1994-11-05T08:15:30-05:00 * 2002-01-31T23:00:00.1234-02:00 * 1991-02-20T06:35:26.079043+00:00 Otherwise, ONLY dates with milliseconds will match the pattern: * 2010-05-01T01:14:31.876 * 2016-05-24T15:54:14.00000Z * 2002-01-31T23:00:00.1234-02:00 * 1991-02-20T06:35:26.079043+00:00 This change aims to bring the capabilities of the python library into alignment with pact-foundation/docs.pact.io#88, since the existing functionality is a bit liberal and allows tests to pass even in cases where the dates do not conform to the ISO 8601 spec.
This introduces pact.Format.iso_8601_datetime() method to match a string for a full ISO 8601 Date. This method differs does not do any sort of date validation, only checks if the string is according to the ISO 8601 spec. This method differs from `pact.Format.timestamp`, `pact.Format.date` and `pact.Format.time` implementations in that it is more stringent and tests the string for exact match to the ISO 8601 dates format. Without `with_millis` parameter will match string containing ISO 8601 formatted dates as stated bellow: * 2016-12-15T20:16:01 * 2010-05-01T01:14:31.876 * 2016-05-24T15:54:14.00000Z * 1994-11-05T08:15:30-05:00 * 2002-01-31T23:00:00.1234-02:00 * 1991-02-20T06:35:26.079043+00:00 Otherwise, ONLY dates with milliseconds will match the pattern: * 2010-05-01T01:14:31.876 * 2016-05-24T15:54:14.00000Z * 2002-01-31T23:00:00.1234-02:00 * 1991-02-20T06:35:26.079043+00:00 This change aims to bring the capabilities of the python library into alignment with pact-foundation/docs.pact.io#88, since the existing functionality is a bit liberal and allows tests to pass even in cases where the dates do not conform to the ISO 8601 spec.
This introduces `pact.Format.iso_8601_datetime()` method to match a string for a full ISO 8601 Date. This method does not do any sort of date validation, only checks if the string is according to the ISO 8601 spec. It differs from `pact.Format.timestamp`, `pact.Format.date` and `pact.Format.time` implementations in that it is more stringent and tests the string for exact match to the ISO 8601 dates format. Without `with_millis` parameter will match string containing ISO 8601 formatted dates as stated bellow: * 2016-12-15T20:16:01 * 2010-05-01T01:14:31.876 * 2016-05-24T15:54:14.00000Z * 1994-11-05T08:15:30-05:00 * 2002-01-31T23:00:00.1234-02:00 * 1991-02-20T06:35:26.079043+00:00 Otherwise, ONLY dates with milliseconds will match the pattern: * 2010-05-01T01:14:31.876 * 2016-05-24T15:54:14.00000Z * 2002-01-31T23:00:00.1234-02:00 * 1991-02-20T06:35:26.079043+00:00 This change aims to bring the capabilities of the python library into alignment with pact-foundation/docs.pact.io#88, since the existing functionality is a bit liberal and allows tests to pass even in cases where the dates do not conform to the ISO 8601 spec.
This introduces `pact.Format.iso_8601_datetime()` method to match a string for a full ISO 8601 Date. This method does not do any sort of date validation, only checks if the string is according to the ISO 8601 spec. It differs from `pact.Format.timestamp`, `pact.Format.date` and `pact.Format.time` implementations in that it is more stringent and tests the string for exact match to the ISO 8601 dates format. Without `with_ms` parameter will match string containing ISO 8601 formatted dates as stated bellow: * 2016-12-15T20:16:01 * 2010-05-01T01:14:31.876 * 2016-05-24T15:54:14.00000Z * 1994-11-05T08:15:30-05:00 * 2002-01-31T23:00:00.1234-02:00 * 1991-02-20T06:35:26.079043+00:00 Otherwise, ONLY dates with milliseconds will match the pattern: * 2010-05-01T01:14:31.876 * 2016-05-24T15:54:14.00000Z * 2002-01-31T23:00:00.1234-02:00 * 1991-02-20T06:35:26.079043+00:00 This change aims to bring the capabilities of the python library into alignment with pact-foundation/docs.pact.io#88, since the existing functionality is a bit liberal and allows tests to pass even in cases where the dates do not conform to the ISO 8601 spec.
Has this changed, because it does not reflect https://github.com/pact-foundation/pact-specification/tree/version-4#supported-generators and I can already see that causing confusion. For example the date-time here has timezone information. While I can see that could be optional, it's not explicit which of the two sources should be canonical; which makes reviewing or understanding difficult. IMO both should be valid date-time signatures. |
https://docs.pact.io/getting_started/matching
The text was updated successfully, but these errors were encountered: