From 36a39929d34fdd39f169f166fd55372b7fac1097 Mon Sep 17 00:00:00 2001 From: Ronald Holshausen Date: Wed, 15 Nov 2023 16:41:22 +1100 Subject: [PATCH] chore: cleanup some unecessary files --- features/V4/http_consumer.feature | 26 --------- features/V4/http_provider.feature | 29 --------- features/V4/matching_rules.feature | 94 ------------------------------ features/V4/v4.feature | 9 --- 4 files changed, 158 deletions(-) delete mode 100644 features/V4/http_consumer.feature delete mode 100644 features/V4/http_provider.feature delete mode 100644 features/V4/matching_rules.feature delete mode 100644 features/V4/v4.feature diff --git a/features/V4/http_consumer.feature b/features/V4/http_consumer.feature deleted file mode 100644 index 79f85fabe..000000000 --- a/features/V4/http_consumer.feature +++ /dev/null @@ -1,26 +0,0 @@ -@consumer -Feature: HTTP consumer - Supports V4 HTTP consumer interactions - - Scenario: Sets the type for the interaction - Given an HTTP interaction is being defined for a consumer test - When the Pact file for the test is generated - Then the first interaction in the Pact file will have a type of "Synchronous/HTTP" - - Scenario: Supports specifying a key for the interaction - Given an HTTP interaction is being defined for a consumer test - And a key of "123ABC" is specified for the HTTP interaction - When the Pact file for the test is generated - Then the first interaction in the Pact file will have "key" = '"123ABC"' - - Scenario: Supports specifying the interaction is pending - Given an HTTP interaction is being defined for a consumer test - And the HTTP interaction is marked as pending - When the Pact file for the test is generated - Then the first interaction in the Pact file will have "pending" = 'true' - - Scenario: Supports adding comments - Given an HTTP interaction is being defined for a consumer test - And a comment "this is a comment" is added to the HTTP interaction - When the Pact file for the test is generated - Then the first interaction in the Pact file will have "comments" = '{"text":["this is a comment"]}' diff --git a/features/V4/http_provider.feature b/features/V4/http_provider.feature deleted file mode 100644 index be3d1ff53..000000000 --- a/features/V4/http_provider.feature +++ /dev/null @@ -1,29 +0,0 @@ -@provider -Feature: HTTP provider - Supports verifying a HTTP provider using V4 features - - Background: - Given the following HTTP interactions have been defined: - | No | method | path | query | headers | body | response | response headers | response content | response body | - | 1 | GET | /basic | | | | 200 | | application/json | file: basic.json | - - Scenario: Verifying a pending HTTP interaction - Given a provider is started that returns the response from interaction 1, with the following changes: - | body | - | file: basic2.json | - And a Pact file for interaction 1 is to be verified, but is marked pending - When the verification is run - Then the verification will be successful - And there will be a pending "Body had differences" error - - Scenario: Verifying a HTTP interaction with comments - Given a provider is started that returns the response from interaction 1 - And a Pact file for interaction 1 is to be verified with the following comments: - | comment | type | - | comment one | text | - | comment two | text | - | compatibility-suite | testname | - When the verification is run - Then the comment "comment one" will have been printed to the console - And the comment "comment two" will have been printed to the console - And the "compatibility-suite" will displayed as the original test name diff --git a/features/V4/matching_rules.feature b/features/V4/matching_rules.feature deleted file mode 100644 index 839c0ef09..000000000 --- a/features/V4/matching_rules.feature +++ /dev/null @@ -1,94 +0,0 @@ -Feature: V4 era Matching Rules - - Scenario: Supports a status code matcher (positive case) - Given an expected response configured with the following: - | status | matching rules | - | 200 | statuscode-matcher-v4.json | - And a status 299 response is received - When the response is compared to the expected one - Then the response comparison should be OK - - Scenario: Supports a status code matcher (negative case) - Given an expected response configured with the following: - | status | matching rules | - | 200 | statuscode-matcher-v4.json | - And a status 400 response is received - When the response is compared to the expected one - Then the response comparison should NOT be OK - And the response mismatches will contain a "status" mismatch with error "expected Successful response (200–299) but was 400" - - Scenario: Supports a not empty matcher (positive case) - Given an expected request configured with the following: - | body | matching rules | - | JSON: { "one": "", "two": ["b"] } | notempty-matcher-v4.json | - And a request is received with the following: - | body | - | JSON: { "one": "cat", "two": ["rat"] } | - When the request is compared to the expected one - Then the comparison should be OK - - Scenario: Supports a not empty matcher with binary data (positive case) - Given an expected request configured with the following: - | body | matching rules | - | file: rat.jpg | notempty2-matcher-v4.json | - And a request is received with the following: - | body | - | file: spider.jpg | - When the request is compared to the expected one - Then the comparison should be OK - - Scenario: Supports a not empty matcher (negative case) - Given an expected request configured with the following: - | body | matching rules | - | JSON: { "one": "a", "two": ["b"] } | notempty-matcher-v4.json | - And a request is received with the following: - | body | - | JSON: { "one": "", "two": [] } | - When the request is compared to the expected one - Then the comparison should NOT be OK - And the mismatches will contain a mismatch with error "$.one" -> "Expected '' (String) to not be empty" - And the mismatches will contain a mismatch with error "$.two" -> "Expected [] (ArrayList) to not be empty" - - Scenario: Supports a not empty matcher (negative case 2, types are different) - Given an expected request configured with the following: - | body | matching rules | - | JSON: { "one": "a", "two": ["b"] } | notempty-matcher-v4.json | - And a request is received with the following: - | body | - | JSON: { "one": "a", "two": "b" } | - When the request is compared to the expected one - Then the comparison should NOT be OK - And the mismatches will contain a mismatch with error "$.two" -> "Type mismatch: Expected String 'b' to be equal to List [\"b\"]" - - Scenario: Supports a not empty matcher with binary data (negative case) - Given an expected request configured with the following: - | body | matching rules | - | file: rat.jpg | notempty2-matcher-v4.json | - And a request is received with the following: - | body | - | | - When the request is compared to the expected one - Then the comparison should NOT be OK - And the mismatches will contain a mismatch with error "$" -> "Expected 0 byte(s) (byte[]) to not be empty" - - Scenario: Supports a semver matcher (positive case) - Given an expected request configured with the following: - | body | matching rules | - | file: basic.json | semver-matcher-v4.json | - And a request is received with the following: - | body | - | JSON: { "one": "1.0.0", "two": "2.0.0" } | - When the request is compared to the expected one - Then the comparison should be OK - - Scenario: Supports a semver matcher (negative case) - Given an expected request configured with the following: - | body | matching rules | - | file: basic.json | semver-matcher-v4.json | - And a request is received with the following: - | body | - | JSON: { "one": "1.0", "two": "1.0abc" } | - When the request is compared to the expected one - Then the comparison should NOT be OK - And the mismatches will contain a mismatch with error "$.one" -> "Expected '1.0' (String) to be a semantic version" - And the mismatches will contain a mismatch with error "$.two" -> "Expected '1.0abc' (String) to be a semantic version" diff --git a/features/V4/v4.feature b/features/V4/v4.feature deleted file mode 100644 index ba316b84a..000000000 --- a/features/V4/v4.feature +++ /dev/null @@ -1,9 +0,0 @@ -Feature: General V4 features - Supports general V4 features - - Scenario: Supports different types of interactions in the Pact file - Given an HTTP interaction is being defined for a consumer test - And a message interaction is being defined for a consumer test - When the Pact file for the test is generated - Then the first interaction in the Pact file will have a type of "Synchronous/HTTP" - Then the second interaction in the Pact file will have a type of "Asynchronous/Messages"