Skip to content

Commit 8fd8d50

Browse files
rholshausenrholshausen
committed
chore: fix pact-compatibility-suite subtree
1 parent c1964a1 commit 8fd8d50

File tree

5 files changed

+173
-0
lines changed

5 files changed

+173
-0
lines changed

‎compatibility-suite/pact-compatibility-suite/.github/workflows/triage.yml

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
name: Triage Issue
2+
3+
on:
4+
issues:
5+
types:
6+
- opened
7+
- labeled
8+
pull_request:
9+
types:
10+
- labeled
11+
12+
jobs:
13+
call-workflow:
14+
uses: pact-foundation/.github/.github/workflows/triage.yml@master
15+
secrets: inherit

‎compatibility-suite/pact-compatibility-suite/features/V4/http_consumer.feature

Lines changed: 26 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
@consumer
2+
Feature: HTTP consumer
3+
Supports V4 HTTP consumer interactions
4+
5+
Scenario: Sets the type for the interaction
6+
Given an HTTP interaction is being defined for a consumer test
7+
When the Pact file for the test is generated
8+
Then the first interaction in the Pact file will have a type of "Synchronous/HTTP"
9+
10+
Scenario: Supports specifying a key for the interaction
11+
Given an HTTP interaction is being defined for a consumer test
12+
And a key of "123ABC" is specified for the HTTP interaction
13+
When the Pact file for the test is generated
14+
Then the first interaction in the Pact file will have "key" = '"123ABC"'
15+
16+
Scenario: Supports specifying the interaction is pending
17+
Given an HTTP interaction is being defined for a consumer test
18+
And the HTTP interaction is marked as pending
19+
When the Pact file for the test is generated
20+
Then the first interaction in the Pact file will have "pending" = 'true'
21+
22+
Scenario: Supports adding comments
23+
Given an HTTP interaction is being defined for a consumer test
24+
And a comment "this is a comment" is added to the HTTP interaction
25+
When the Pact file for the test is generated
26+
Then the first interaction in the Pact file will have "comments" = '{"text":["this is a comment"]}'

‎compatibility-suite/pact-compatibility-suite/features/V4/http_provider.feature

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
@provider
2+
Feature: HTTP provider
3+
Supports verifying a HTTP provider using V4 features
4+
5+
Background:
6+
Given the following HTTP interactions have been defined:
7+
| No | method | path | query | headers | body | response | response headers | response content | response body |
8+
| 1 | GET | /basic | | | | 200 | | application/json | file: basic.json |
9+
10+
Scenario: Verifying a pending HTTP interaction
11+
Given a provider is started that returns the response from interaction 1, with the following changes:
12+
| body |
13+
| file: basic2.json |
14+
And a Pact file for interaction 1 is to be verified, but is marked pending
15+
When the verification is run
16+
Then the verification will be successful
17+
And there will be a pending "Body had differences" error
18+
19+
Scenario: Verifying a HTTP interaction with comments
20+
Given a provider is started that returns the response from interaction 1
21+
And a Pact file for interaction 1 is to be verified with the following comments:
22+
| comment | type |
23+
| comment one | text |
24+
| comment two | text |
25+
| compatibility-suite | testname |
26+
When the verification is run
27+
Then the comment "comment one" will have been printed to the console
28+
And the comment "comment two" will have been printed to the console
29+
And the "compatibility-suite" will displayed as the original test name

‎compatibility-suite/pact-compatibility-suite/features/V4/matching_rules.feature

Lines changed: 94 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,94 @@
1+
Feature: V4 era Matching Rules
2+
3+
Scenario: Supports a status code matcher (positive case)
4+
Given an expected response configured with the following:
5+
| status | matching rules |
6+
| 200 | statuscode-matcher-v4.json |
7+
And a status 299 response is received
8+
When the response is compared to the expected one
9+
Then the response comparison should be OK
10+
11+
Scenario: Supports a status code matcher (negative case)
12+
Given an expected response configured with the following:
13+
| status | matching rules |
14+
| 200 | statuscode-matcher-v4.json |
15+
And a status 400 response is received
16+
When the response is compared to the expected one
17+
Then the response comparison should NOT be OK
18+
And the response mismatches will contain a "status" mismatch with error "expected Successful response (200–299) but was 400"
19+
20+
Scenario: Supports a not empty matcher (positive case)
21+
Given an expected request configured with the following:
22+
| body | matching rules |
23+
| JSON: { "one": "", "two": ["b"] } | notempty-matcher-v4.json |
24+
And a request is received with the following:
25+
| body |
26+
| JSON: { "one": "cat", "two": ["rat"] } |
27+
When the request is compared to the expected one
28+
Then the comparison should be OK
29+
30+
Scenario: Supports a not empty matcher with binary data (positive case)
31+
Given an expected request configured with the following:
32+
| body | matching rules |
33+
| file: rat.jpg | notempty2-matcher-v4.json |
34+
And a request is received with the following:
35+
| body |
36+
| file: spider.jpg |
37+
When the request is compared to the expected one
38+
Then the comparison should be OK
39+
40+
Scenario: Supports a not empty matcher (negative case)
41+
Given an expected request configured with the following:
42+
| body | matching rules |
43+
| JSON: { "one": "a", "two": ["b"] } | notempty-matcher-v4.json |
44+
And a request is received with the following:
45+
| body |
46+
| JSON: { "one": "", "two": [] } |
47+
When the request is compared to the expected one
48+
Then the comparison should NOT be OK
49+
And the mismatches will contain a mismatch with error "$.one" -> "Expected '' (String) to not be empty"
50+
And the mismatches will contain a mismatch with error "$.two" -> "Expected [] (ArrayList) to not be empty"
51+
52+
Scenario: Supports a not empty matcher (negative case 2, types are different)
53+
Given an expected request configured with the following:
54+
| body | matching rules |
55+
| JSON: { "one": "a", "two": ["b"] } | notempty-matcher-v4.json |
56+
And a request is received with the following:
57+
| body |
58+
| JSON: { "one": "a", "two": "b" } |
59+
When the request is compared to the expected one
60+
Then the comparison should NOT be OK
61+
And the mismatches will contain a mismatch with error "$.two" -> "Type mismatch: Expected String 'b' to be equal to List [\"b\"]"
62+
63+
Scenario: Supports a not empty matcher with binary data (negative case)
64+
Given an expected request configured with the following:
65+
| body | matching rules |
66+
| file: rat.jpg | notempty2-matcher-v4.json |
67+
And a request is received with the following:
68+
| body |
69+
| |
70+
When the request is compared to the expected one
71+
Then the comparison should NOT be OK
72+
And the mismatches will contain a mismatch with error "$" -> "Expected 0 byte(s) (byte[]) to not be empty"
73+
74+
Scenario: Supports a semver matcher (positive case)
75+
Given an expected request configured with the following:
76+
| body | matching rules |
77+
| file: basic.json | semver-matcher-v4.json |
78+
And a request is received with the following:
79+
| body |
80+
| JSON: { "one": "1.0.0", "two": "2.0.0" } |
81+
When the request is compared to the expected one
82+
Then the comparison should be OK
83+
84+
Scenario: Supports a semver matcher (negative case)
85+
Given an expected request configured with the following:
86+
| body | matching rules |
87+
| file: basic.json | semver-matcher-v4.json |
88+
And a request is received with the following:
89+
| body |
90+
| JSON: { "one": "1.0", "two": "1.0abc" } |
91+
When the request is compared to the expected one
92+
Then the comparison should NOT be OK
93+
And the mismatches will contain a mismatch with error "$.one" -> "Expected '1.0' (String) to be a semantic version"
94+
And the mismatches will contain a mismatch with error "$.two" -> "Expected '1.0abc' (String) to be a semantic version"

‎compatibility-suite/pact-compatibility-suite/features/V4/v4.feature

Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
Feature: General V4 features
2+
Supports general V4 features
3+
4+
Scenario: Supports different types of interactions in the Pact file
5+
Given an HTTP interaction is being defined for a consumer test
6+
And a message interaction is being defined for a consumer test
7+
When the Pact file for the test is generated
8+
Then the first interaction in the Pact file will have a type of "Synchronous/HTTP"
9+
Then the second interaction in the Pact file will have a type of "Asynchronous/Messages"

0 commit comments

Comments
 (0)