From f6fa6e3fe1da4c8fa8a7285f844c3187252365b3 Mon Sep 17 00:00:00 2001 From: Ronald Holshausen Date: Thu, 13 Feb 2025 10:06:48 +1100 Subject: [PATCH] Squashed 'compatibility-suite/pact-compatibility-suite/' changes from 416f3a64d..cc76eac3c cc76eac3c fix: Never coerce number values from strings when dealing with bodies b8e9a2aa0 Merge pull request #11 from pact-foundation/feat/use-consistent-fixture-headers 65f86c442 feat: use consistent fixture headers 870c4790f chore: Configure Renovate (#9) 4a3c411cd chore: add smartbear supported jira integration git-subtree-dir: compatibility-suite/pact-compatibility-suite git-subtree-split: cc76eac3ca649e863c9d28aad572605922545759 --- .github/renovate.json | 7 +++ .../workflows/smartbear-issue-label-added.yml | 11 ++++ features/V1/http_provider.feature | 20 +++--- features/V2/http_provider.feature | 10 +-- features/V3/matching_rules.feature | 61 +++++++++++++++---- features/V4/http_provider.feature | 2 +- fixtures/decimal-type-matcher-v3.json | 20 ++++++ fixtures/integer-type-matcher-v3.json | 20 ++++++ fixtures/number-type-matcher-v3.json | 20 ++++++ 9 files changed, 142 insertions(+), 29 deletions(-) create mode 100644 .github/renovate.json create mode 100644 .github/workflows/smartbear-issue-label-added.yml diff --git a/.github/renovate.json b/.github/renovate.json new file mode 100644 index 000000000..def7a3722 --- /dev/null +++ b/.github/renovate.json @@ -0,0 +1,7 @@ +{ + "$schema": "https://docs.renovatebot.com/renovate-schema.json", + "extends": ["config:best-practices"], + "prHourlyLimit": 0, + "prConcurrentLimit": 0, + "automerge": true +} \ No newline at end of file diff --git a/.github/workflows/smartbear-issue-label-added.yml b/.github/workflows/smartbear-issue-label-added.yml new file mode 100644 index 000000000..8b68fed74 --- /dev/null +++ b/.github/workflows/smartbear-issue-label-added.yml @@ -0,0 +1,11 @@ +name: SmartBear Supported Issue Label Added + +on: + issues: + types: + - labeled + +jobs: + call-workflow: + uses: pact-foundation/.github/.github/workflows/smartbear-issue-label-added.yml@master + secrets: inherit diff --git a/features/V1/http_provider.feature b/features/V1/http_provider.feature index 94fda4477..283811676 100644 --- a/features/V1/http_provider.feature +++ b/features/V1/http_provider.feature @@ -118,16 +118,16 @@ Feature: Basic HTTP provider Scenario: Verifies the response status code Given a provider is started that returns the response from interaction 1, with the following changes: - | status | - | 400 | + | response | + | 400 | And a Pact file for interaction 1 is to be verified When the verification is run Then the verification will NOT be successful And the verification results will contain a "Response status did not match" error Scenario: Verifies the response headers - Given a provider is started that returns the response from interaction 1, with the following changes: - | headers | + Given a provider is started that returns the response from interaction 5, with the following changes: + | response headers | | 'X-TEST: Compatibility' | And a Pact file for interaction 5 is to be verified When the verification is run @@ -142,7 +142,7 @@ Feature: Basic HTTP provider Scenario: Response with plain text body (negative case) Given a provider is started that returns the response from interaction 6, with the following changes: - | body | + | response body | | Hello Compatibility Suite! | And a Pact file for interaction 6 is to be verified When the verification is run @@ -157,7 +157,7 @@ Feature: Basic HTTP provider Scenario: Response with JSON body (negative case) Given a provider is started that returns the response from interaction 1, with the following changes: - | body | + | response body | | JSON: { "one": 100, "two": "b" } | And a Pact file for interaction 1 is to be verified When the verification is run @@ -172,7 +172,7 @@ Feature: Basic HTTP provider Scenario: Response with XML body (negative case) Given a provider is started that returns the response from interaction 7, with the following changes: - | body | + | response body | | XML: A | And a Pact file for interaction 7 is to be verified When the verification is run @@ -187,7 +187,7 @@ Feature: Basic HTTP provider Scenario: Response with binary body (negative case) Given a provider is started that returns the response from interaction 8, with the following changes: - | body | + | response body | | file: spider.jpg | And a Pact file for interaction 8 is to be verified When the verification is run @@ -202,7 +202,7 @@ Feature: Basic HTTP provider Scenario: Response with form post body (negative case) Given a provider is started that returns the response from interaction 9, with the following changes: - | body | + | response body | | a=1&b=2&c=33&d=4 | And a Pact file for interaction 9 is to be verified When the verification is run @@ -217,7 +217,7 @@ Feature: Basic HTTP provider Scenario: Response with multipart body (negative case) Given a provider is started that returns the response from interaction 10, with the following changes: - | body | + | response body | | file: multipart2-body.xml | And a Pact file for interaction 10 is to be verified When the verification is run diff --git a/features/V2/http_provider.feature b/features/V2/http_provider.feature index d51df8b4d..57c58e794 100644 --- a/features/V2/http_provider.feature +++ b/features/V2/http_provider.feature @@ -10,15 +10,15 @@ Feature: Basic HTTP provider Scenario: Supports matching rules for the response headers (positive case) Given a provider is started that returns the response from interaction 1, with the following changes: - | headers | - | 'X-TEST: 1000' | + | response headers | + | 'X-TEST: 1000' | And a Pact file for interaction 1 is to be verified When the verification is run Then the verification will be successful Scenario: Supports matching rules for the response headers (negative case) Given a provider is started that returns the response from interaction 1, with the following changes: - | headers | + | response headers | | 'X-TEST: 123ABC' | And a Pact file for interaction 1 is to be verified When the verification is run @@ -27,7 +27,7 @@ Feature: Basic HTTP provider Scenario: Verifies the response body (positive case) Given a provider is started that returns the response from interaction 2, with the following changes: - | body | + | response body | | JSON: { "one": "100", "two": "b" } | And a Pact file for interaction 2 is to be verified When the verification is run @@ -35,7 +35,7 @@ Feature: Basic HTTP provider Scenario: Verifies the response body (negative case) Given a provider is started that returns the response from interaction 2, with the following changes: - | body | + | response body | | JSON: { "one": 100, "two": "b" } | And a Pact file for interaction 2 is to be verified When the verification is run diff --git a/features/V3/matching_rules.feature b/features/V3/matching_rules.feature index 7dd079d77..ec9af8e64 100644 --- a/features/V3/matching_rules.feature +++ b/features/V3/matching_rules.feature @@ -65,18 +65,31 @@ Feature: V3 era Matching Rules When the requests are compared to the expected one Then the comparison should be OK + Scenario: Supports a number type matcher where it is acceptable to coerce values from string form + Given an expected request configured with the following: + | query | headers | matching rules | + | a=1234 | 'X-A: 1234' | number-type-matcher-v3.json | + And the following requests are received: + | query | headers | desc | + | a=100 | 'X-A: 100' | Integer number | + | a=100.2 | 'X-A: 100.4' | Floating point number | + When the requests are compared to the expected one + Then the comparison should be OK + Scenario: Supports a number type matcher (negative case) Given an expected request configured with the following: | body | matching rules | | file: basic.json | number-type-matcher-v3.json | And the following requests are received: - | body | desc | - | JSON: { "one": true, "two": "b" } | Boolean | - | JSON: { "one": "100X01", "two": "b" } | String | + | body | desc | + | JSON: { "one": true, "two": "b" } | Boolean | + | JSON: { "one": "100X01", "two": "b" } | String | + | JSON: { "one": "100", "two": "b" } | Number in string form is not acceptable in bodies | When the requests are compared to the expected one Then the comparison should NOT be OK And the mismatches will contain a mismatch with error "$.one" -> "Expected true (Boolean) to be a number" And the mismatches will contain a mismatch with error "$.one" -> "Expected '100X01' (String) to be a number" + And the mismatches will contain a mismatch with error "$.one" -> "Expected '100' (String) to be a number" Scenario: Supports an integer type matcher, no digits after the decimal point (positive case) Given an expected request configured with the following: @@ -85,7 +98,16 @@ Feature: V3 era Matching Rules And the following requests are received: | body | desc | | JSON: { "one": 100, "two": "b" } | Integer number | - | JSON: { "one": "100", "two": "b" } | String representation of an integer | + When the requests are compared to the expected one + Then the comparison should be OK + + Scenario: Supports an integer type matcher where it is acceptable to coerce values from string form + Given an expected request configured with the following: + | query | headers | matching rules | + | a=1234 | 'X-A: 1234' | number-type-matcher-v3.json | + And the following requests are received: + | query | headers | desc | + | a=100 | 'X-A: 100' | Integer number | When the requests are compared to the expected one Then the comparison should be OK @@ -94,15 +116,17 @@ Feature: V3 era Matching Rules | body | matching rules | | file: basic.json | integer-type-matcher-v3.json | And the following requests are received: - | body | desc | - | JSON: { "one": [], "two": "b" } | Array | - | JSON: { "one": 100.1, "two": "b" } | Floating point number | - | JSON: { "one": "100X01", "two": "b" } | Not a string representation of an integer | + | body | desc | + | JSON: { "one": [], "two": "b" } | Array | + | JSON: { "one": 100.1, "two": "b" } | Floating point number | + | JSON: { "one": "100X01", "two": "b" } | String | + | JSON: { "one": "100", "two": "b" } | String representation of an integer is not acceptable in bodies | When the requests are compared to the expected one Then the comparison should NOT be OK And the mismatches will contain a mismatch with error "$.one" -> "Expected [] (Array) to be an integer" And the mismatches will contain a mismatch with error "$.one" -> "Expected 100.1 (Decimal) to be an integer" And the mismatches will contain a mismatch with error "$.one" -> "Expected '100X01' (String) to be an integer" + And the mismatches will contain a mismatch with error "$.one" -> "Expected '100' (String) to be an integer" Scenario: Supports an decimal type matcher, must have significant digits after the decimal point (positive case) Given an expected request configured with the following: @@ -111,7 +135,6 @@ Feature: V3 era Matching Rules And the following requests are received: | body | desc | | JSON: { "one": 100.1234, "two": "b" } | Floating point number | - | JSON: { "one": "100.1234", "two": "b" } | String representation of a floating point number | When the requests are compared to the expected one Then the comparison should be OK @@ -120,15 +143,27 @@ Feature: V3 era Matching Rules | body | matching rules | | file: basic.json | decimal-type-matcher-v3.json | And the following requests are received: - | body | desc | - | JSON: { "one": null, "two": "b" } | Null | - | JSON: { "one": 100, "two": "b" } | Integer number | - | JSON: { "one": "100X01", "two": "b" } | Not a string representation of an decimal number | + | body | desc | + | JSON: { "one": null, "two": "b" } | Null | + | JSON: { "one": 100, "two": "b" } | Integer number | + | JSON: { "one": "100X01", "two": "b" } | String value | + | JSON: { "one": "100.1234", "two": "b" } | String representation of a floating point number is not acceptable in bodies | When the requests are compared to the expected one Then the comparison should NOT be OK And the mismatches will contain a mismatch with error "$.one" -> "Expected null (Null) to be a decimal number" And the mismatches will contain a mismatch with error "$.one" -> "Expected 100 (Integer) to be a decimal number" And the mismatches will contain a mismatch with error "$.one" -> "Expected '100X01' (String) to be a decimal number" + And the mismatches will contain a mismatch with error "$.one" -> "Expected '100.1234' (String) to be a decimal number" + + Scenario: Supports a decimal type matcher where it is acceptable to coerce values from string form + Given an expected request configured with the following: + | query | headers | matching rules | + | a=1234.0 | 'X-A: 1234.0' | number-type-matcher-v3.json | + And the following requests are received: + | query | headers | desc | + | a=100.2 | 'X-A: 100.4' | Floating point number | + When the requests are compared to the expected one + Then the comparison should be OK Scenario: Supports a null matcher (positive case) Given an expected request configured with the following: diff --git a/features/V4/http_provider.feature b/features/V4/http_provider.feature index be3d1ff53..8e15a1371 100644 --- a/features/V4/http_provider.feature +++ b/features/V4/http_provider.feature @@ -9,7 +9,7 @@ Feature: HTTP provider Scenario: Verifying a pending HTTP interaction Given a provider is started that returns the response from interaction 1, with the following changes: - | body | + | response body | | file: basic2.json | And a Pact file for interaction 1 is to be verified, but is marked pending When the verification is run diff --git a/fixtures/decimal-type-matcher-v3.json b/fixtures/decimal-type-matcher-v3.json index b1ddc4180..74a76f443 100644 --- a/fixtures/decimal-type-matcher-v3.json +++ b/fixtures/decimal-type-matcher-v3.json @@ -7,6 +7,26 @@ "match": "decimal" } ] + }, + "query": { + "a": { + "combine": "AND", + "matchers": [ + { + "match": "decimal" + } + ] + } + }, + "header": { + "X-A": { + "combine": "AND", + "matchers": [ + { + "match": "decimal" + } + ] + } } } } diff --git a/fixtures/integer-type-matcher-v3.json b/fixtures/integer-type-matcher-v3.json index 0418a6133..ab3edd591 100644 --- a/fixtures/integer-type-matcher-v3.json +++ b/fixtures/integer-type-matcher-v3.json @@ -8,5 +8,25 @@ } ] } + }, + "query": { + "a": { + "combine": "AND", + "matchers": [ + { + "match": "integer" + } + ] + } + }, + "header": { + "X-A": { + "combine": "AND", + "matchers": [ + { + "match": "integer" + } + ] + } } } diff --git a/fixtures/number-type-matcher-v3.json b/fixtures/number-type-matcher-v3.json index 3a1ca2d24..ca9e618c6 100644 --- a/fixtures/number-type-matcher-v3.json +++ b/fixtures/number-type-matcher-v3.json @@ -8,5 +8,25 @@ } ] } + }, + "query": { + "a": { + "combine": "AND", + "matchers": [ + { + "match": "number" + } + ] + } + }, + "header": { + "X-A": { + "combine": "AND", + "matchers": [ + { + "match": "number" + } + ] + } } }