Merge commit 'f6fa6e3fe1da4c8fa8a7285f844c3187252365b3'

pact-foundation · Feb 12, 2025 · 8789492 · 8789492
2 parents c3938b4 + f6fa6e3
commit 8789492
Show file tree

Hide file tree

Showing 9 changed files with 142 additions and 29 deletions.
diff --git a/compatibility-suite/pact-compatibility-suite/.github/renovate.json b/compatibility-suite/pact-compatibility-suite/.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
+}
diff --git a/...tibility-suite/pact-compatibility-suite/.github/workflows/smartbear-issue-label-added.yml b/...tibility-suite/pact-compatibility-suite/.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/compatibility-suite/pact-compatibility-suite/features/V1/http_provider.feature b/compatibility-suite/pact-compatibility-suite/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: <?xml version="1.0" encoding="UTF-8" ?><values><one>A</one></values> |
     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/compatibility-suite/pact-compatibility-suite/features/V2/http_provider.feature b/compatibility-suite/pact-compatibility-suite/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,15 +27,15 @@ 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
     Then the verification will be successful
 
   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/compatibility-suite/pact-compatibility-suite/features/V3/matching_rules.feature b/compatibility-suite/pact-compatibility-suite/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/compatibility-suite/pact-compatibility-suite/features/V4/http_provider.feature b/compatibility-suite/pact-compatibility-suite/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/compatibility-suite/pact-compatibility-suite/fixtures/decimal-type-matcher-v3.json b/compatibility-suite/pact-compatibility-suite/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/compatibility-suite/pact-compatibility-suite/fixtures/integer-type-matcher-v3.json b/compatibility-suite/pact-compatibility-suite/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/compatibility-suite/pact-compatibility-suite/fixtures/number-type-matcher-v3.json b/compatibility-suite/pact-compatibility-suite/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"
+        }
+      ]
+    }
   }
 }