Download jvm-bridge JAR file with all dependencies

A template repository for Kotlin Multiplatform projects

pact-jvm-loggin --------------- Inlined logging from https://github.com/typesafehub/scalalogging to support both Scala 2.10 and 2.11

Pact consumer ============= Pact Consumer is used by projects that are consumers of an API. Most projects will want to use pact-consumer via one of the test framework specific projects. If your favourite framework is not implemented, this module should give you all the hooks you need. Provides a DSL for use with Java to build consumer pacts. ## Dependency The library is available on maven central using: * group-id = `au.com.dius` * artifact-id = `pact-jvm-consumer_2.11` ## DSL Usage Example in a JUnit test: ```java import au.com.dius.pact.model.MockProviderConfig; import au.com.dius.pact.model.PactFragment; import org.junit.Test; import java.io.IOException; import java.util.HashMap; import java.util.Map; import static org.junit.Assert.assertEquals; public class PactTest { @Test public void testPact() { PactFragment pactFragment = ConsumerPactBuilder .consumer("Some Consumer") .hasPactWith("Some Provider") .uponReceiving("a request to say Hello") .path("/hello") .method("POST") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") .toFragment(); MockProviderConfig config = MockProviderConfig.createDefault(); VerificationResult result = pactFragment.runConsumer(config, new TestRun() { @Override public void run(MockProviderConfig config) { Map expectedResponse = new HashMap(); expectedResponse.put("hello", "harry"); try { assertEquals(new ProviderClient(config.url()).hello("{\"name\": \"harry\"}"), expectedResponse); } catch (IOException e) {} } }); if (result instanceof PactError) { throw new RuntimeException(((PactError)result).error()); } assertEquals(ConsumerPactTest.PACT_VERIFIED, result); } } ``` The DSL has the following pattern: ```java .consumer("Some Consumer") .hasPactWith("Some Provider") .given("a certain state on the provider") .uponReceiving("a request for something") .path("/hello") .method("POST") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") .uponReceiving("another request for something") .path("/hello") .method("POST") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") . . . .toFragment() ``` You can define as many interactions as required. Each interaction starts with `uponReceiving` followed by `willRespondWith`. The test state setup with `given` is a mechanism to describe what the state of the provider should be in before the provider is verified. It is only recorded in the consumer tests and used by the provider verification tasks. ### Building JSON bodies with PactDslJsonBody DSL The body method of the ConsumerPactBuilder can accept a PactDslJsonBody, which can construct a JSON body as well as define regex and type matchers. For example: ```java PactDslJsonBody body = new PactDslJsonBody() .stringType("name") .booleanType("happy") .hexValue("hexCode") .id() .ipAddress("localAddress") .numberValue("age", 100) .timestamp(); ``` #### DSL Matching methods The following matching methods are provided with the DSL. In most cases, they take an optional value parameter which will be used to generate example values (i.e. when returning a mock response). If no example value is given, a random one will be generated. | method | description | |--------|-------------| | string, stringValue | Match a string value (using string equality) | | number, numberValue | Match a number value (using Number.equals)\* | | booleanValue | Match a boolean value (using equality) | | stringType | Will match all Strings | | numberType | Will match all numbers\* | | integerType | Will match all numbers that are integers (both ints and longs)\* | | decimalType | Will match all real numbers (floating point and decimal)\* | | booleanType | Will match all boolean values (true and false) | | stringMatcher | Will match strings using the provided regular expression | | timestamp | Will match string containing timestamps. If a timestamp format is not given, will match an ISO timestamp format | | date | Will match string containing dates. If a date format is not given, will match an ISO date format | | time | Will match string containing times. If a time format is not given, will match an ISO time format | | ipAddress | Will match string containing IP4 formatted address. | | id | Will match all numbers by type | | hexValue | Will match all hexadecimal encoded strings | | uuid | Will match strings containing UUIDs | _\* Note:_ JSON only supports double precision floating point values. Depending on the language implementation, they may parsed as integer, floating point or decimal numbers. #### Ensuring all items in a list match an example (2.2.0+) Lots of the time you might not know the number of items that will be in a list, but you want to ensure that the list has a minimum or maximum size and that each item in the list matches a given example. You can do this with the `arrayLike`, `minArrayLike` and `maxArrayLike` functions. | function | description | |----------|-------------| | `eachLike` | Ensure that each item in the list matches the provided example | | `maxArrayLike` | Ensure that each item in the list matches the provided example and the list is no bigger than the provided max | | `minArrayLike` | Ensure that each item in the list matches the provided example and the list is no smaller than the provided min | For example: ```java DslPart body = new PactDslJsonBody() .minArrayLike("users") .id() .stringType("name") .closeObject() .closeArray(); ``` This will ensure that the users list is never empty and that each user has an identifier that is a number and a name that is a string. #### Matching JSON values at the root (Version 3.2.2/2.4.3+) For cases where you are expecting basic JSON values (strings, numbers, booleans and null) at the root level of the body and need to use matchers, you can use the `PactDslJsonRootValue` class. It has all the DSL matching methods for basic values that you can use. For example: ```java .consumer("Some Consumer") .hasPactWith("Some Provider") .uponReceiving("a request for a basic JSON value") .path("/hello") .willRespondWith() .status(200) .body(PactDslJsonRootValue.integerType()) ``` #### Root level arrays that match all items (version 2.2.11+) If the root of the body is an array, you can create PactDslJsonArray classes with the following methods: | function | description | |----------|-------------| | `arrayEachLike` | Ensure that each item in the list matches the provided example | | `arrayMinLike` | Ensure that each item in the list matches the provided example and the list is no bigger than the provided max | | `arrayMaxLike` | Ensure that each item in the list matches the provided example and the list is no smaller than the provided min | For example: ```java PactDslJsonArray.arrayEachLike() .date("clearedDate", "mm/dd/yyyy", date) .stringType("status", "STATUS") .decimalType("amount", 100.0) .closeObject() ``` This will then match a body like: ```json [ { "clearedDate" : "07/22/2015", "status" : "C", "amount" : 15.0 }, { "clearedDate" : "07/22/2015", "status" : "C", "amount" : 15.0 }, { "clearedDate" : "07/22/2015", "status" : "C", "amount" : 15.0 } ] ``` #### Matching arrays of arrays (version 3.2.12/2.4.14+) For the case where you have arrays of arrays (GeoJSON is an example), the following methods have been provided: | function | description | |----------|-------------| | `eachArrayLike` | Ensure that each item in the array is an array that matches the provided example | | `eachArrayWithMaxLike` | Ensure that each item in the array is an array that matches the provided example and the array is no bigger than the provided max | | `eachArrayWithMinLike` | Ensure that each item in the array is an array that matches the provided example and the array is no smaller than the provided min | For example (with GeoJSON structure): ```java new PactDslJsonBody() .stringType("type","FeatureCollection") .eachLike("features") .stringType("type","Feature") .object("geometry") .stringType("type","Point") .eachArrayLike("coordinates") // coordinates is an array of arrays .decimalType(-7.55717) .decimalType(49.766896) .closeArray() .closeArray() .closeObject() .object("properties") .stringType("prop0","value0") .closeObject() .closeObject() .closeArray() ``` This generated the following JSON: ```json { "features": [ { "geometry": { "coordinates": [[-7.55717, 49.766896]], "type": "Point" }, "type": "Feature", "properties": { "prop0": "value0" } } ], "type": "FeatureCollection" } ``` and will be able to match all coordinates regardless of the number of coordinates. #### Matching any key in a map (3.3.1/2.5.0+) The DSL has been extended for cases where the keys in a map are IDs. For an example of this, see [#313](https://github.com/DiUS/pact-jvm/issues/131). In this case you can use the `eachKeyLike` method, which takes an example key as a parameter. For example: ```java DslPart body = new PactDslJsonBody() .object("one") .eachKeyLike("001", PactDslJsonRootValue.id(12345L)) // key like an id mapped to a matcher .closeObject() .object("two") .eachKeyLike("001-A") // key like an id where the value is matched by the following example .stringType("description", "Some Description") .closeObject() .closeObject() .object("three") .eachKeyMappedToAnArrayLike("001") // key like an id mapped to an array where each item is matched by the following example .id("someId", 23456L) .closeObject() .closeArray() .closeObject(); ``` For an example, have a look at [WildcardKeysTest](src/test/java/au/com/dius/pact/consumer/WildcardKeysTest.java). **NOTE:** The `eachKeyLike` method adds a `*` to the matching path, so the matching definition will be applied to all keys of the map if there is not a more specific matcher defined for a particular key. Having more than one `eachKeyLike` condition applied to a map will result in only one being applied when the pact is verified (probably the last). ### Matching on paths (version 2.1.5+) You can use regular expressions to match incoming requests. The DSL has a `matchPath` method for this. You can provide a real path as a second value to use when generating requests, and if you leave it out it will generate a random one from the regular expression. For example: ```java .given("test state") .uponReceiving("a test interaction") .matchPath("/transaction/[0-9]+") // or .matchPath("/transaction/[0-9]+", "/transaction/1234567890") .method("POST") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") ``` ### Matching on headers (version 2.2.2+) You can use regular expressions to match request and response headers. The DSL has a `matchHeader` method for this. You can provide an example header value to use when generating requests and responses, and if you leave it out it will generate a random one from the regular expression. For example: ```java .given("test state") .uponReceiving("a test interaction") .path("/hello") .method("POST") .matchHeader("testreqheader", "test.*value") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") .matchHeader("Location", ".*/hello/[0-9]+", "/hello/1234") ``` ### Matching on query parameters (version 3.3.7+) You can use regular expressions to match request query parameters. The DSL has a `matchQuery` method for this. You can provide an example value to use when generating requests, and if you leave it out it will generate a random one from the regular expression. For example: ```java .given("test state") .uponReceiving("a test interaction") .path("/hello") .method("POST") .matchQuery("a", "\\d+", "100") .matchQuery("b", "[A-Z]", "X") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") ```

pact-jvm-consumer-specs2 ======================== ## Specs2 Bindings for the pact-jvm library ## Dependency In the root folder of your project in build.sbt add the line: ```scala libraryDependencies += "au.com.dius" %% "pact-jvm-consumer-specs2" % "3.2.2" ``` or if you are using Gradle: ```groovy dependencies { testCompile "au.com.dius:pact-jvm-consumer-specs2_2.11:3.2.2" } ``` __*Note:*__ `PactSpec` requires spec2 3.x. Also, for spray users there's an incompatibility between specs2 v3.x and spray. Follow these instructions to resolve that problem: https://groups.google.com/forum/#!msg/spray-user/2T6SBp4OJeI/AJlnJuAKPRsJ ## Usage To author a test, mix `PactSpec` into your spec First we define a service client called `ConsumerService`. In our example this is a simple wrapper for `dispatch`, an HTTP client. The source code can be found in the test folder alongside the `ExamplePactSpec`. Here is a simple example: ``` import au.com.dius.pact.consumer.PactSpec class ExamplePactSpec extends Specification with PactSpec { val consumer = "My Consumer" val provider = "My Provider" override def is = uponReceiving("a request for foo") .matching(path = "/foo") .willRespondWith(body = "{}") .withConsumerTest { providerConfig => Await.result(ConsumerService(providerConfig.url).simpleGet("/foo"), Duration(1000, MILLISECONDS)) must beEqualTo(200, Some("{}")) } } ``` This spec will be run along with the rest of your specs2 unit tests and will output your pact json to ``` /target/pacts/<Consumer>_<Provider>.json ```

pact-jvm-consumer-junit ======================= Provides a DSL and a base test class for use with Junit to build consumer tests. ##Dependency The library is available on maven central using: * group-id = `au.com.dius` * artifact-id = `pact-jvm-consumer-junit_2.11` * version-id = `3.0.x` ##Usage ### Using the base ConsumerPactTest To write a pact spec extend ConsumerPactTestMk2. This base class defines the following four methods which must be overridden in your test class. * *providerName:* Returns the name of the API provider that Pact will mock * *consumerName:* Returns the name of the API consumer that we are testing. * *createFragment:* Returns the PactFragment containing the interactions that the test setup using the ConsumerPactBuilder DSL * *runTest:* The actual test run. It receives the URL to the mock server as a parameter. Here is an example: ```java import au.com.dius.pact.consumer.dsl.PactDslWithProvider; import au.com.dius.pact.consumer.exampleclients.ConsumerClient; import au.com.dius.pact.consumer.ConsumerPactTest; import au.com.dius.pact.model.PactFragment; import org.junit.Assert; import java.io.IOException; import java.util.HashMap; import java.util.Map; import static org.junit.Assert.assertEquals; public class ExampleJavaConsumerPactTest extends ConsumerPactTest { @Override protected PactFragment createFragment(PactDslWithProvider builder) { Map<String, String> headers = new HashMap<String, String>(); headers.put("testreqheader", "testreqheadervalue"); return builder .given("test state") // NOTE: Using provider states are optional, you can leave it out .uponReceiving("ExampleJavaConsumerPactTest test interaction") .path("/") .method("GET") .headers(headers) .willRespondWith() .status(200) .headers(headers) .body("{\"responsetest\": true, \"name\": \"harry\"}") .given("test state 2") // NOTE: Using provider states are optional, you can leave it out .uponReceiving("ExampleJavaConsumerPactTest second test interaction") .method("OPTIONS") .headers(headers) .path("/second") .body("") .willRespondWith() .status(200) .headers(headers) .body("") .toFragment(); } @Override protected String providerName() { return "test_provider"; } @Override protected String consumerName() { return "test_consumer"; } @Override protected void runTest(String url) throws IOException { Assert.assertEquals(new ConsumerClient(url).options("/second"), 200); Map expectedResponse = new HashMap(); expectedResponse.put("responsetest", true); expectedResponse.put("name", "harry"); assertEquals(new ConsumerClient(url).getAsMap("/", ""), expectedResponse); assertEquals(new ConsumerClient(url).options("/second"), 200); } } ``` ### Using the Pact JUnit Rule Thanks to [@warmuuh](https://github.com/warmuuh) we have a JUnit rule that simplifies running Pact consumer tests. To use it, create a test class and then add the rule: #### 1. Add the Pact Rule to your test class to represent your provider. ```java @Rule public PactProviderRule mockProvider = new PactProviderRule("test_provider", "localhost", 8080, this); ``` The hostname and port are optional. If left out, it will default to localhost and a random available port. #### 2. Annotate a method with Pact that returns a pact fragment for the provider and consumer ```java @Pact(provider="test_provider", consumer="test_consumer") public PactFragment createFragment(PactDslWithProvider builder) { return builder .given("test state") .uponReceiving("ExampleJavaConsumerPactRuleTest test interaction") .path("/") .method("GET") .willRespondWith() .status(200) .body("{\"responsetest\": true}") .toFragment(); } ``` ##### Versions 3.0.2/2.2.13+ You can leave the provider name out. It will then use the provider name of the first mock provider found. I.e., ```java @Pact(consumer="test_consumer") // will default to the provider name from mockProvider public PactFragment createFragment(PactDslWithProvider builder) { return builder .given("test state") .uponReceiving("ExampleJavaConsumerPactRuleTest test interaction") .path("/") .method("GET") .willRespondWith() .status(200) .body("{\"responsetest\": true}") .toFragment(); } ``` #### 3. Annotate your test method with PactVerification to have it run in the context of the mock server setup with the appropriate pact from step 1 and 2 ```java @Test @PactVerification("test_provider") public void runTest() { Map expectedResponse = new HashMap(); expectedResponse.put("responsetest", true); assertEquals(new ConsumerClient("http://localhost:8080").get("/"), expectedResponse); } ``` ##### Versions 3.0.2/2.2.13+ You can leave the provider name out. It will then use the provider name of the first mock provider found. I.e., ```java @Test @PactVerification public void runTest() { // This will run against mockProvider Map expectedResponse = new HashMap(); expectedResponse.put("responsetest", true); assertEquals(new ConsumerClient("http://localhost:8080").get("/"), expectedResponse); } ``` For an example, have a look at [ExampleJavaConsumerPactRuleTest](src/test/java/au/com/dius/pact/consumer/examples/ExampleJavaConsumerPactRuleTest.java) ### Requiring a test with multiple providers The Pact Rule can be used to test with multiple providers. Just add a rule to the test class for each provider, and then include all the providers required in the `@PactVerification` annotation. For an example, look at [PactMultiProviderTest](src/test/java/au/com/dius/pact/consumer/pactproviderrule/PactMultiProviderTest.java). Note that if more than one provider fails verification for the same test, you will only receive a failure for one of them. Also, to have multiple tests in the same test class, the providers must be setup with random ports (i.e. don't specify a hostname and port). Also, if the provider name is left out of any of the annotations, the first one found will be used (which may not be the first one defined). ### Requiring the mock server to run with HTTPS [versions 3.2.7/2.4.9+] From versions 3.2.7/2.4.9+ the mock server can be started running with HTTPS using a self-signed certificate instead of HTTP. To enable this set the `https` parameter to `true`. E.g.: ```java @Rule public PactProviderRule mockTestProvider = new PactProviderRule("test_provider", "localhost", 8443, true, PactConfig.apply(PactSpecVersion.V2), this); // ^^^^ ``` For an exmaple test doing this, see [PactProviderHttpsTest](src/test/java/au/com/dius/pact/consumer/pactproviderrule/PactProviderHttpsTest.java). **NOTE:** The provider will start handling HTTPS requests using a self-signed certificate. Most HTTP clients will not accept connections to a self-signed server as the certificate is untrusted. You may need to enable insecure HTTPS with your client for this test to work. For an example of how to enable insecure HTTPS client connections with Apache Http Client, have a look at [InsecureHttpsRequest](src/test/java/org/apache/http/client/fluent/InsecureHttpsRequest.java). ### Using the Pact DSL directly Sometimes it is not convenient to use the ConsumerPactTest as it only allows one test per test class. The DSL can be used directly in this case. Example: ```java import au.com.dius.pact.consumer.ConsumerPactBuilder; import au.com.dius.pact.consumer.ConsumerPactTest; import au.com.dius.pact.consumer.PactError; import au.com.dius.pact.consumer.TestRun; import au.com.dius.pact.consumer.VerificationResult; import au.com.dius.pact.consumer.examples.client.ProviderClient; import au.com.dius.pact.model.MockProviderConfig; import au.com.dius.pact.model.PactFragment; import org.junit.Test; import java.io.IOException; import java.util.HashMap; import java.util.Map; import static org.junit.Assert.assertEquals; public class PactTest { @Test public void testPact() { PactFragment pactFragment = ConsumerPactBuilder .consumer("Some Consumer") .hasPactWith("Some Provider") .uponReceiving("a request to say Hello") .path("/hello") .method("POST") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") .toFragment(); MockProviderConfig config = MockProviderConfig.createDefault(); VerificationResult result = pactFragment.runConsumer(config, new TestRun() { @Override public void run(MockProviderConfig config) { Map expectedResponse = new HashMap(); expectedResponse.put("hello", "harry"); try { assertEquals(new ProviderClient(config.url()).hello("{\"name\": \"harry\"}"), expectedResponse); } catch (IOException e) { throw new RuntimeException(e); } } }); if (result instanceof PactError) { throw new RuntimeException(((PactError)result).error()); } assertEquals(ConsumerPactTest.PACT_VERIFIED, result); } } ``` ### The Pact JUnit DSL The DSL has the following pattern: ```java .consumer("Some Consumer") .hasPactWith("Some Provider") .given("a certain state on the provider") .uponReceiving("a request for something") .path("/hello") .method("POST") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") .uponReceiving("another request for something") .path("/hello") .method("POST") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") . . . .toFragment() ``` You can define as many interactions as required. Each interaction starts with `uponReceiving` followed by `willRespondWith`. The test state setup with `given` is a mechanism to describe what the state of the provider should be in before the provider is verified. It is only recorded in the consumer tests and used by the provider verification tasks. ### Building JSON bodies with PactDslJsonBody DSL The body method of the ConsumerPactBuilder can accept a PactDslJsonBody, which can construct a JSON body as well as define regex and type matchers. For example: ```java PactDslJsonBody body = new PactDslJsonBody() .stringType("name") .booleanType("happy") .hexValue("hexCode") .id() .ipAddress("localAddress") .numberValue("age", 100) .timestamp(); ``` #### DSL Matching methods The following matching methods are provided with the DSL. In most cases, they take an optional value parameter which will be used to generate example values (i.e. when returning a mock response). If no example value is given, a random one will be generated. | method | description | |--------|-------------| | string, stringValue | Match a string value (using string equality) | | number, numberValue | Match a number value (using Number.equals)\* | | booleanValue | Match a boolean value (using equality) | | stringType | Will match all Strings | | numberType | Will match all numbers\* | | integerType | Will match all numbers that are integers (both ints and longs)\* | | decimalType | Will match all real numbers (floating point and decimal)\* | | booleanType | Will match all boolean values (true and false) | | stringMatcher | Will match strings using the provided regular expression | | timestamp | Will match string containing timestamps. If a timestamp format is not given, will match an ISO timestamp format | | date | Will match string containing dates. If a date format is not given, will match an ISO date format | | time | Will match string containing times. If a time format is not given, will match an ISO time format | | ipAddress | Will match string containing IP4 formatted address. | | id | Will match all numbers by type | | hexValue | Will match all hexadecimal encoded strings | | uuid | Will match strings containing UUIDs | _\* Note:_ JSON only supports double precision floating point values. Depending on the language implementation, they may parsed as integer, floating point or decimal numbers. #### Ensuring all items in a list match an example (2.2.0+) Lots of the time you might not know the number of items that will be in a list, but you want to ensure that the list has a minimum or maximum size and that each item in the list matches a given example. You can do this with the `arrayLike`, `minArrayLike` and `maxArrayLike` functions. | function | description | |----------|-------------| | `eachLike` | Ensure that each item in the list matches the provided example | | `maxArrayLike` | Ensure that each item in the list matches the provided example and the list is no bigger than the provided max | | `minArrayLike` | Ensure that each item in the list matches the provided example and the list is no smaller than the provided min | For example: ```java DslPart body = new PactDslJsonBody() .minArrayLike("users", 1) .id() .stringType("name") .closeObject() .closeArray(); ``` This will ensure that the users list is never empty and that each user has an identifier that is a number and a name that is a string. __Version 3.2.4/2.4.6+__ You can specify the number of example items to generate in the array. The default is 1. ```java DslPart body = new PactDslJsonBody() .minArrayLike("users", 1, 2) .id() .stringType("name") .closeObject() .closeArray(); ``` This will generate the example body with 2 items in the users list. #### Root level arrays that match all items (version 2.2.11+) If the root of the body is an array, you can create PactDslJsonArray classes with the following methods: | function | description | |----------|-------------| | `arrayEachLike` | Ensure that each item in the list matches the provided example | | `arrayMinLike` | Ensure that each item in the list matches the provided example and the list is no bigger than the provided max | | `arrayMaxLike` | Ensure that each item in the list matches the provided example and the list is no smaller than the provided min | For example: ```java PactDslJsonArray.arrayEachLike() .date("clearedDate", "mm/dd/yyyy", date) .stringType("status", "STATUS") .decimalType("amount", 100.0) .closeObject() ``` This will then match a body like: ```json [ { "clearedDate" : "07/22/2015", "status" : "C", "amount" : 15.0 }, { "clearedDate" : "07/22/2015", "status" : "C", "amount" : 15.0 }, { "clearedDate" : "07/22/2015", "status" : "C", "amount" : 15.0 } ] ``` __Version 3.2.4/2.4.6+__ You can specify the number of example items to generate in the array. The default is 1. #### Matching JSON values at the root (Version 3.2.2/2.4.3+) For cases where you are expecting basic JSON values (strings, numbers, booleans and null) at the root level of the body and need to use matchers, you can use the `PactDslJsonRootValue` class. It has all the DSL matching methods for basic values that you can use. For example: ```java .consumer("Some Consumer") .hasPactWith("Some Provider") .uponReceiving("a request for a basic JSON value") .path("/hello") .willRespondWith() .status(200) .body(PactDslJsonRootValue.integerType()) ``` #### Matching any key in a map (3.3.1/2.5.0+) The DSL has been extended for cases where the keys in a map are IDs. For an example of this, see [#313](https://github.com/DiUS/pact-jvm/issues/313). In this case you can use the `eachKeyLike` method, which takes an example key as a parameter. For example: ```java DslPart body = new PactDslJsonBody() .object("one") .eachKeyLike("001", PactDslJsonRootValue.id(12345L)) // key like an id mapped to a matcher .closeObject() .object("two") .eachKeyLike("001-A") // key like an id where the value is matched by the following example .stringType("description", "Some Description") .closeObject() .closeObject() .object("three") .eachKeyMappedToAnArrayLike("001") // key like an id mapped to an array where each item is matched by the following example .id("someId", 23456L) .closeObject() .closeArray() .closeObject(); ``` For an example, have a look at [WildcardKeysTest](src/test/java/au/com/dius/pact/consumer/WildcardKeysTest.java). **NOTE:** The `eachKeyLike` method adds a `*` to the matching path, so the matching definition will be applied to all keys of the map if there is not a more specific matcher defined for a particular key. Having more than one `eachKeyLike` condition applied to a map will result in only one being applied when the pact is verified (probably the last). ### Matching on paths (version 2.1.5+) You can use regular expressions to match incoming requests. The DSL has a `matchPath` method for this. You can provide a real path as a second value to use when generating requests, and if you leave it out it will generate a random one from the regular expression. For example: ```java .given("test state") .uponReceiving("a test interaction") .matchPath("/transaction/[0-9]+") // or .matchPath("/transaction/[0-9]+", "/transaction/1234567890") .method("POST") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") ``` ### Matching on headers (version 2.2.2+) You can use regular expressions to match request and response headers. The DSL has a `matchHeader` method for this. You can provide an example header value to use when generating requests and responses, and if you leave it out it will generate a random one from the regular expression. For example: ```java .given("test state") .uponReceiving("a test interaction") .path("/hello") .method("POST") .matchHeader("testreqheader", "test.*value") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") .matchHeader("Location", ".*/hello/[0-9]+", "/hello/1234") ``` ### Matching on query parameters (version 3.3.7+) You can use regular expressions to match request query parameters. The DSL has a `matchQuery` method for this. You can provide an example value to use when generating requests, and if you leave it out it will generate a random one from the regular expression. For example: ```java .given("test state") .uponReceiving("a test interaction") .path("/hello") .method("POST") .matchQuery("a", "\\d+", "100") .matchQuery("b", "[A-Z]", "X") .body("{\"name\": \"harry\"}") .willRespondWith() .status(200) .body("{\"hello\": \"harry\"}") ``` ## Debugging pact failures When the test runs, Pact will start a mock provider that will listen for requests and match them against the expectations you setup in `createFragment`. If the request does not match, it will return a 500 error response. Each request received and the generated response is logged using [SLF4J](http://www.slf4j.org/). Just enable debug level logging for au.com.dius.pact.consumer.UnfilteredMockProvider. Most failures tend to be mismatched headers or bodies. ## Changing the directory pact files are written to (2.1.9+) By default, pact files are written to `target/pacts`, but this can be overwritten with the `pact.rootDir` system property. This property needs to be set on the test JVM as most build tools will fork a new JVM to run the tests. For Gradle, add this to your build.gradle: ```groovy test { systemProperties['pact.rootDir'] = "$buildDir/pacts" } ``` For maven, use the systemPropertyVariables configuration: ```xml <project> [...] <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <version>2.18</version> <configuration> <systemPropertyVariables> <pact.rootDir>some/other/directory</pact.rootDir> <buildDirectory>${project.build.directory}</buildDirectory> [...] </systemPropertyVariables> </configuration> </plugin> </plugins> </build> [...] </project> ``` For SBT: ```scala fork in Test := true, javaOptions in Test := Seq("-Dpact.rootDir=some/other/directory") ``` # Publishing your pact files to a pact broker If you use Gradle, you can use the [pact Gradle plugin](https://github.com/DiUS/pact-jvm/tree/master/pact-jvm-provider-gradle#publishing-pact-files-to-a-pact-broker) to publish your pact files. # Pact Specification V3 Version 3 of the pact specification changes the format of pact files in the following ways: * Query parameters are stored in a map form and are un-encoded (see [#66](https://github.com/DiUS/pact-jvm/issues/66) and [#97](https://github.com/DiUS/pact-jvm/issues/97) for information on what this can cause). * Introduces a new message pact format for testing interactions via a message queue. ## Generating V3 spec pact files (3.1.0+, 2.3.0+) To have your consumer tests generate V3 format pacts, you can set the specification version to V3. If you're using the `ConsumerPactTest` base class, you can override the `getSpecificationVersion` method. For example: ```java @Override protected PactSpecVersion getSpecificationVersion() { return PactSpecVersion.V3; } ``` If you are using the `PactProviderRule`, you can pass the version into the constructor for the rule. ```java @Rule public PactProviderRule mockTestProvider = new PactProviderRule("test_provider", PactSpecVersion.V3, this); ``` ## Consumer test for a message consumer For testing a consumer of messages from a message queue, the `MessagePactProviderRule` rule class works in much the same way as the `PactProviderRule` class for Request-Response interactions, but will generate a V3 format message pact file. For an example, look at [ExampleMessageConsumerTest](https://github.com/DiUS/pact-jvm/blob/master/pact-jvm-consumer-junit%2Fsrc%2Ftest%2Fjava%2Fau%2Fcom%2Fdius%2Fpact%2Fconsumer%2Fv3%2FExampleMessageConsumerTest.java)

Multi-threaded | Parallel Cucumber-JVM | Parallelize your Java Cucumber tests on a feature level or on a scenario level.

jvm-sdk

Pact server =========== The pact server is a stand-alone interactions recorder and verifier, aimed at clients that are non-JVM or non-Ruby based. The pact client for that platform will need to be implemented, but it only be responsible for generating the `JSON` interactions, running the tests and communicating with the server. The server implements a `JSON` `REST` Admin API with the following endpoints. / -> For diagnostics, currently returns a list of ports of the running mock servers. /create -> For initialising a test server and submitting the JSON interactions. It returns a port /complete -> For finalising and verifying the interactions with the server. It writes the `JSON` pact file to disk. ## Running the server ### Versions 2.2.6+ Pact server takes the following parameters: ``` Usage: pact-jvm-server [options] [port] port port to run on (defaults to 29999) --help prints this usage text -h <value> | --host <value> host to bind to (defaults to localhost) -l <value> | --mock-port-lower <value> lower bound to allocate mock ports (defaults to 20000) -u <value> | --mock-port-upper <value> upper bound to allocate mock ports (defaults to 40000) -d | --daemon run as a daemon process --debug run with debug logging ``` ### Prior to version 2.2.6 Pact server takes one optional parameter, the port number to listen on. If not provided, it will listen on 29999. It requires an active console to run. ### Using a distribution archive You can download a [distribution from maven central](http://search.maven.org/remotecontent?filepath=au/com/dius/pact-jvm-server_2.11/2.2.4/). There is both a ZIP and TAR archive. Unpack it to a directory of choice and then run the script in the bin directory. ### Building a distribution bundle You can build an application bundle with gradle by running (for 2.11 version): $ ./gradlew :pact-jvm-server_2.11:installdist This will create an app bundle in `build/2.11/install/pact-jvm-server_2.11`. You can then execute it with: $ java -jar pact-jvm-server/build/2.10/install/pact-jvm-server_2.11/lib/pact-jvm-server_2.11-2.2.4.jar or with the generated bundle script file: $ pact-jvm-server/build/2.11/install/pact-jvm-server_2.11/bin/pact-jvm-server_2.11 By default will run on port `29999` but a port number can be optionally supplied. ### Running it with docker You can use a docker image to execute the mock server as a docker container. $ docker run -d -p 8080:8080 -p 20000-20010:20000-20010 uglyog/pact-jvm-server This will run the main server on port 8080, and each created mock server on ports 20000-20010. You can map the ports to any you require. ## Life cycle The following actions are expected to occur * The client calls `/create` to initialise a server with the expected `JSON` interactions and state * The admin server will start a mock server on a random port and return the port number in the response * The client will execute its interaction tests against the mock server with the supplied port * Once finished, the client will call `/complete' on the Admin API, posting the port number * The pact server will verify the interactions and write the `JSON` `pact` file to disk under `/target` * The mock server running on the supplied port will be shutdown. ## Endpoints ### /create The client will need `POST` to `/create` the generated `JSON` interactions, also providing a state as a query parameter. For example: POST http://localhost:29999/create?state=NoUsers '{ "provider": { "name": "Animal_Service"}, ... }' This will create a new running mock service provider on a randomly generated port. The port will be returned in the `201` response: { "port" : 34423 } ### /complete Once the client has finished running its tests against the mock server on the supplied port (in this example port `34423`) the client will need to `POST` to `/complete` the port number of the mock server that was used. For example: POST http://localhost:29999/complete '{ "port" : 34423 }' This will cause the Pact server to verify the interactions, shutdown the mock server running on that port and writing the pact `JSON` file to disk under the `target` directory. ### / The `/` endpoint is for diagnostics and to check that the pact server is running. It will return all the currently running mock servers port numbers. For example: GET http://localhost:29999/ '{ "ports": [23443,43232] }'

A plugin to upload cucumber test results into ALM Octane. The plugin works with the Junit framework that runs cucumber-jvm tests.

Pact provider ============= sub project of https://github.com/DiUS/pact-jvm The pact provider is responsible for verifying that an API provider adheres to a number of pacts authored by its clients This library provides the basic tools required to automate the process, and should be usable on its own in many instances. Framework and build tool specific bindings will be provided in separate libraries that build on top of this core functionality. ### Running Pacts Main takes 2 arguments: The first is the root folder of your pact files (all .json files in root and subfolders are assumed to be pacts) The second is the location of your pact config json file. ### Pact config The pact config is a simple mapping of provider names to endpoint url's paths will be appended to endpoint url's when interactions are attempted for an example see: https://github.com/DiUS/pact-jvm/blob/master/pact-jvm-provider/src/test/resources/pact-config.json ### Provider State Before each interaction is executed, the provider under test will have the opportunity to enter a state. Generally the state maps to a set of fixture data for mocking out services that the provider is a consumer of (they will have their own pacts) The pact framework will instruct the test server to enter that state by sending: POST "${config.stateChangeUrl.url}/setup" { "state" : "${interaction.stateName}" } ### An example of running provider verification with junit This example uses java, junit and hamcrest matchers to run the provider verification. As the provider service is a DropWizard application, it uses the DropwizardAppRule to startup the service before running any test. Warning: It only grabs the first interaction from the pact file with the consumer, where there could be many. (This could possibly be solved with a parameterized test) ```java public class PactJVMProviderJUnitTest { @ClassRule public static TestRule startServiceRule = new DropwizardAppRule<DropwizardAppConfig>(DropwizardApp.class, "config.yml"); private static ProviderInfo serviceProvider; private static Pact testConsumerPact; @BeforeClass public static void setupProvider() { serviceProvider = new ProviderInfo("Dropwizard App"); serviceProvider.setProtocol("http"); serviceProvider.setHost("localhost"); serviceProvider.setPort(8080); serviceProvider.setPath("/"); ConsumerInfo consumer = new ConsumerInfo(); consumer.setName("test_consumer"); consumer.setPactFile(new File("target/pacts/ping_client-ping_service.json")); // serviceProvider.getConsumers().add(consumer); testConsumerPact = (Pact) new PactReader().loadPact(consumer.getPactFile()); } @Test @SuppressWarnings("unchecked") public void runConsumerPacts() { //grab the first interaction from the pact with consumer List<Interaction> interactions = scala.collection.JavaConversions.seqAsJavaList(testConsumerPact.interactions()); Interaction interaction1 = interactions.get(0); //setup any provider state //setup the client and interaction to fire against the provider ProviderClient client = new ProviderClient(); client.setProvider(serviceProvider); client.setRequest(interaction1.request()); Map<String, Object> clientResponse = (Map<String, Object>) client.makeRequest(); Map<String, Object> result = (Map<String, Object>) ResponseComparison.compareResponse(interaction1.response(), clientResponse, (int) clientResponse.get("statusCode"), (Map) clientResponse.get("headers"), (String) clientResponse.get("data")); //assert all good assertThat(result.get("method"), is(true)); // method type matches Map headers = (Map) result.get("headers"); //headers match headers.forEach( (k, v) -> assertThat(format("Header: [%s] does not match", k), v, org.hamcrest.Matchers.equalTo(true)) ); assertThat((Collection<Object>)((Map)result.get("body")).values(), org.hamcrest.Matchers.hasSize(0)); // empty list of body mismatches } } ``` ### An example of running provider verification with spock This example uses groovy and spock to run the provider verification. Again the provider service is a DropWizard application, and is using the DropwizardAppRule to startup the service. This example runs all interactions using spocks Unroll feature ```groovy class PactJVMProviderSpockSpec extends Specification { @ClassRule @Shared TestRule startServiceRule = new DropwizardAppRule<DropwizardAppConfig>(DropwizardApp.class, "config.yml"); @Shared ProviderInfo serviceProvider @Shared Pact testConsumerPact def setupSpec() { serviceProvider = new ProviderInfo("Dropwizard App") serviceProvider.protocol = "http" serviceProvider.host = "localhost" serviceProvider.port = 8080; serviceProvider.path = "/" def consumer = serviceProvider.hasPactWith("ping_consumer", { pactFile = new File('target/pacts/ping_client-ping_service.json') }) testConsumerPact = (Pact) new PactReader().loadPact(consumer.getPactFile()); } def cleanup() { //cleanup provider state //ie. db.truncateAllTables() } def cleanupSpec() { //cleanup provider } @Unroll def "Provider Pact - With Consumer"() { given: //setup provider state // ie. db.setupRecords() // serviceProvider.requestFilter = { req -> // req.addHeader('Authorization', token) // } when: ProviderClient client = new ProviderClient(provider: serviceProvider, request: interaction.request()) Map clientResponse = (Map) client.makeRequest() Map result = (Map) ResponseComparison.compareResponse(interaction.response(), clientResponse, clientResponse.statusCode, clientResponse.headers, clientResponse.data) then: // method matches result.method == true // headers all match, spock needs the size checked before // asserting each result if (result.headers.size() > 0) { result.headers.each() { k, v -> assert v == true } } // empty list of body mismatches result.body.size() == 0 where: interaction << scala.collection.JavaConversions.seqAsJavaList(testConsumerPact.interactions()) } } ```

pact-jvm-provider-specs2 ======================== Provides an extension to Specs2 Specification to validate a pact file against a running provider. See [ExampleProviderSpec.scala](pact-jvm-provider-specs2/src/test/scala/au/com/dius/pact/provider/specs2/ExampleProviderSpec.scala) for an example. *Note:* The Pact ProviderSpec requires spec2 3.x

Maven plugin to verify a provider ================================= Maven plugin for verifying pacts against a provider. The Maven plugin provides a `verify` goal which will verify all configured pacts against your provider. ## To Use It ### 1. Add the pact-jvm-provider-maven plugin to your `build` section of your pom file. ```xml &lt;build&gt; [...] &lt;plugins&gt; [...] &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;/plugin&gt; [...] &lt;/plugins&gt; [...] &lt;/build&gt; ``` ### 2. Define the pacts between your consumers and providers You define all the providers and consumers within the configuration element of the maven plugin. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;!-- You can define as many as you need, but each must have a unique name --&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;!-- All the provider properties are optional, and have sensible defaults (shown below) --&gt; &lt;protocol&gt;http&lt;/protocol&gt; &lt;host&gt;localhost&lt;/host&gt; &lt;port&gt;8080&lt;/port&gt; &lt;path&gt;/&lt;/path&gt; &lt;consumers&gt; &lt;!-- Again, you can define as many consumers for each provider as you need, but each must have a unique name --&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;!-- currently supports a file path using pactFile or a URL using pactUrl --&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ### 3. Execute `mvn pact:verify` You will have to have your provider running for this to pass. ## Verifying all pact files in a directory for a provider You can specify a directory that contains pact files, and the Pact plugin will scan for all pact files that match that provider and define a consumer for each pact file in the directory. Consumer name is read from contents of pact file. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;!-- You can define as many as you need, but each must have a unique name --&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;!-- All the provider properties are optional, and have sensible defaults (shown below) --&gt; &lt;protocol&gt;http&lt;/protocol&gt; &lt;host&gt;localhost&lt;/host&gt; &lt;port&gt;8080&lt;/port&gt; &lt;path&gt;/&lt;/path&gt; &lt;pactFileDirectory&gt;path/to/pacts&lt;/pactFileDirectory&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ### Verifying all pact files from multiple directories for a provider [3.5.18+] If you want to specify multiple directories, you can use `pactFileDirectories`. The plugin will only fail the build if no pact files are loaded after processing all the directories in the list. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.18&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;pactFileDirectories&gt; &lt;pactFileDirectory&gt;path/to/pacts1&lt;/pactFileDirectory&gt; &lt;pactFileDirectory&gt;path/to/pacts2&lt;/pactFileDirectory&gt; &lt;/pactFileDirectories&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Enabling insecure SSL For providers that are running on SSL with self-signed certificates, you need to enable insecure SSL mode by setting `&lt;insecure&gt;true&lt;/insecure&gt;` on the provider. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;pactFileDirectory&gt;path/to/pacts&lt;/pactFileDirectory&gt; &lt;insecure&gt;true&lt;/insecure&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Specifying a custom trust store For environments that are running their own certificate chains: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;pactFileDirectory&gt;path/to/pacts&lt;/pactFileDirectory&gt; &lt;trustStore&gt;relative/path/to/trustStore.jks&lt;/trustStore&gt; &lt;trustStorePassword&gt;changeit&lt;/trustStorePassword&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` `trustStore` is either relative to the current working (build) directory. `trustStorePassword` defaults to `changeit`. NOTE: The hostname will still be verified against the certificate. ## Modifying the requests before they are sent Sometimes you may need to add things to the requests that can&apos;t be persisted in a pact file. Examples of these would be authentication tokens, which have a small life span. The Pact Maven plugin provides a request filter that can be set to a Groovy script on the provider that will be called before the request is made. This script will receive the HttpRequest bound to a variable named `request` prior to it being executed. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;requestFilter&gt; // This is a Groovy script that adds an Authorization header to each request request.addHeader(&apos;Authorization&apos;, &apos;oauth-token eyJhbGciOiJSUzI1NiIsIm...&apos;) &lt;/requestFilter&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` __*Important Note:*__ You should only use this feature for things that can not be persisted in the pact file. By modifying the request, you are potentially modifying the contract from the consumer tests! ## Modifying the HTTP Client Used The default HTTP client is used for all requests to providers (created with a call to `HttpClients.createDefault()`). This can be changed by specifying a closure assigned to createClient on the provider that returns a CloseableHttpClient. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;createClient&gt; // This is a Groovy script that will enable the client to accept self-signed certificates import org.apache.http.ssl.SSLContextBuilder import org.apache.http.conn.ssl.NoopHostnameVerifier import org.apache.http.impl.client.HttpClients HttpClients.custom().setSSLHostnameVerifier(new NoopHostnameVerifier()) .setSslcontext(new SSLContextBuilder().loadTrustMaterial(null, { x509Certificates, s -&gt; true }) .build()) .build() &lt;/createClient&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Turning off URL decoding of the paths in the pact file By default the paths loaded from the pact file will be decoded before the request is sent to the provider. To turn this behaviour off, set the system property `pact.verifier.disableUrlPathDecoding` to `true`. __*Important Note:*__ If you turn off the url path decoding, you need to ensure that the paths in the pact files are correctly encoded. The verifier will not be able to make a request with an invalid encoded path. ## Plugin Properties The following plugin properties can be specified with `-Dproperty=value` on the command line or in the configuration section: |Property|Description| |--------|-----------| |pact.showStacktrace|This turns on stacktrace printing for each request. It can help with diagnosing network errors| |pact.showFullDiff|This turns on displaying the full diff of the expected versus actual bodies| |pact.filter.consumers|Comma separated list of consumer names to verify| |pact.filter.description|Only verify interactions whose description match the provided regular expression| |pact.filter.providerState|Only verify interactions whose provider state match the provided regular expression. An empty string matches interactions that have no state| |pact.verifier.publishResults|Publishing of verification results will be skipped unless this property is set to &apos;true&apos; [version 3.5.18+]| |pact.matching.wildcard|Enables matching of map values ignoring the keys when this property is set to &apos;true&apos;| Example in the configuration section: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;configuration&gt; &lt;pact.showStacktrace&gt;true&lt;/pact.showStacktrace&gt; &lt;/configuration&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Provider States For each provider you can specify a state change URL to use to switch the state of the provider. This URL will receive the providerState description and parameters from the pact file before each interaction via a POST. The stateChangeUsesBody controls if the state is passed in the request body or as query parameters. These values can be set at the provider level, or for a specific consumer. Consumer values take precedent if both are given. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChange&lt;/stateChangeUrl&gt; &lt;stateChangeUsesBody&gt;false&lt;/stateChangeUsesBody&gt; &lt;!-- defaults to true --&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/provider1-consumer1-pact.json&lt;/pactFile&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChangeForConsumer1&lt;/stateChangeUrl&gt; &lt;stateChangeUsesBody&gt;false&lt;/stateChangeUsesBody&gt; &lt;!-- defaults to true --&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` If the `stateChangeUsesBody` is not specified, or is set to true, then the provider state description and parameters will be sent as JSON in the body of the request. If it is set to false, they will passed as query parameters. As for normal requests (see Modifying the requests before they are sent), a state change request can be modified before it is sent. Set `stateChangeRequestFilter` to a Groovy script on the provider that will be called before the request is made. #### Teardown calls for state changes You can enable teardown state change calls by setting the property `&lt;stateChangeTeardown&gt;true&lt;/stateChangeTeardown&gt;` on the provider. This will add an `action` parameter to the state change call. The setup call before the test will receive `action=setup`, and then a teardown call will be made afterwards to the state change URL with `action=teardown`. ## Verifying pact files from a pact broker You can setup your build to validate against the pacts stored in a pact broker. The pact plugin will query the pact broker for all consumers that have a pact with the provider based on its name. To use it, just configure the `pactBrokerUrl` or `pactBroker` value for the provider with the base URL to the pact broker. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChange&lt;/stateChangeUrl&gt; &lt;pactBrokerUrl&gt;http://pact-broker:5000/&lt;/pactBrokerUrl&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ### Verifying pacts from an authenticated pact broker If your pact broker requires authentication (basic authentication is only supported), you can configure the username and password to use by configuring the `authentication` element of the `pactBroker` element of your provider. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChange&lt;/stateChangeUrl&gt; &lt;pactBroker&gt; &lt;url&gt;http://pactbroker:1234&lt;/url&gt; &lt;authentication&gt; &lt;username&gt;test&lt;/username&gt; &lt;password&gt;test&lt;/password&gt; &lt;/authentication&gt; &lt;/pactBroker&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` #### Using the Maven servers configuration [version 3.5.6+] From version 3.5.6, you can use the servers setup in the Maven settings. To do this, setup a server as per the [Maven Server Settings](https://maven.apache.org/settings.html#Servers). Then set the server ID in the pact broker configuration in your POM. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.6&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChange&lt;/stateChangeUrl&gt; &lt;pactBroker&gt; &lt;url&gt;http://pactbroker:1234&lt;/url&gt; &lt;serverId&gt;test-pact-broker&lt;/serverId&gt; &lt;!-- This must match the server id in the maven settings --&gt; &lt;/pactBroker&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ### Verifying pacts from an pact broker that match particular tags If your pacts in your pact broker have been tagged, you can set the tags to fetch by configuring the `tags` element of the `pactBroker` element of your provider. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;provider1&lt;/name&gt; &lt;stateChangeUrl&gt;http://localhost:8080/tasks/pactStateChange&lt;/stateChangeUrl&gt; &lt;pactBroker&gt; &lt;url&gt;http://pactbroker:1234&lt;/url&gt; &lt;tags&gt; &lt;tag&gt;TEST&lt;/tag&gt; &lt;tag&gt;DEV&lt;/tag&gt; &lt;/tags&gt; &lt;/pactBroker&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` This example will fetch and validate the pacts for the TEST and DEV tags. ## Filtering the interactions that are verified You can filter the interactions that are run using three properties: `pact.filter.consumers`, `pact.filter.description` and `pact.filter.providerState`. Adding `-Dpact.filter.consumers=consumer1,consumer2` to the command line or configuration section will only run the pact files for those consumers (consumer1 and consumer2). Adding `-Dpact.filter.description=a request for payment.*` will only run those interactions whose descriptions start with &apos;a request for payment&apos;. `-Dpact.filter.providerState=.*payment` will match any interaction that has a provider state that ends with payment, and `-Dpact.filter.providerState=` will match any interaction that does not have a provider state. ## Not failing the build if no pact files are found [version 3.5.19+] By default, if there are no pact files to verify, the plugin will raise an exception. This is to guard against false positives where the build is passing but nothing has been verified due to mis-configuration. To disable this behaviour, set the `failIfNoPactsFound` parameter to `false`. # Verifying a message provider The Maven plugin has been updated to allow invoking test methods that can return the message contents from a message producer. To use it, set the way to invoke the verification to `ANNOTATED_METHOD`. This will allow the pact verification task to scan for test methods that return the message contents. Add something like the following to your maven pom file: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;messageProvider&lt;/name&gt; &lt;verificationType&gt;ANNOTATED_METHOD&lt;/verificationType&gt; &lt;!-- packagesToScan is optional, but leaving it out will result in the entire test classpath being scanned. Set it to the packages where your annotated test method can be found. --&gt; &lt;packagesToScan&gt; &lt;packageToScan&gt;au.com.example.messageprovider.*&lt;/packageToScan&gt; &lt;/packagesToScan&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/messageprovider-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` Now when the pact verify task is run, will look for methods annotated with `@PactVerifyProvider` in the test classpath that have a matching description to what is in the pact file. ```groovy class ConfirmationKafkaMessageBuilderTest { @PactVerifyProvider(&apos;an order confirmation message&apos;) String verifyMessageForOrder() { Order order = new Order() order.setId(10000004) order.setExchange(&apos;ASX&apos;) order.setSecurityCode(&apos;CBA&apos;) order.setPrice(BigDecimal.TEN) order.setUnits(15) order.setGst(new BigDecimal(&apos;15.0&apos;)) odrer.setFees(BigDecimal.TEN) def message = new ConfirmationKafkaMessageBuilder() .withOrder(order) .build() JsonOutput.toJson(message) } } ``` It will then validate that the returned contents matches the contents for the message in the pact file. ## Changing the class path that is scanned By default, the test classpath is scanned for annotated methods. You can override this by setting the `classpathElements` property: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;serviceProviders&gt; &lt;serviceProvider&gt; &lt;name&gt;messageProvider&lt;/name&gt; &lt;verificationType&gt;ANNOTATED_METHOD&lt;/verificationType&gt; &lt;consumers&gt; &lt;consumer&gt; &lt;name&gt;consumer1&lt;/name&gt; &lt;pactFile&gt;path/to/messageprovider-consumer1-pact.json&lt;/pactFile&gt; &lt;/consumer&gt; &lt;/consumers&gt; &lt;/serviceProvider&gt; &lt;/serviceProviders&gt; &lt;classpathElements&gt; &lt;classpathElement&gt; build/classes/test &lt;/classpathElement&gt; &lt;/classpathElements&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` # Publishing pact files to a pact broker The pact maven plugin provides a `publish` mojo that can publish all pact files in a directory to a pact broker. To use it, you need to add a publish configuration to the POM that defines the directory where the pact files are and the URL to the pact broker. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;pactDirectory&gt;path/to/pact/files&lt;/pactDirectory&gt; &lt;!-- Defaults to ${project.build.directory}/pacts --&gt; &lt;pactBrokerUrl&gt;http://pactbroker:1234&lt;/pactBrokerUrl&gt; &lt;projectVersion&gt;1.0.100&lt;/projectVersion&gt; &lt;!-- Defaults to ${project.version} --&gt; &lt;trimSnapshot&gt;true&lt;/trimSnapshot&gt; &lt;!-- Defaults to false --&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` You can now execute `mvn pact:publish` to publish the pact files. _NOTE:_ The pact broker requires a version for all published pacts. The `publish` task will use the version of the project by default, but can be overwritten with the `projectVersion` property. Make sure you have set one otherwise the broker will reject the pact files. _NOTE_: By default, the pact broker has issues parsing `SNAPSHOT` versions. You can configure the publisher to automatically remove `-SNAPSHOT` from your version number by setting `trimSnapshot` to true. This setting does not modify non-snapshot versions. You can set any tags that the pacts should be published with by setting the `tags` list property (version 3.5.12+). A common use of this is setting the tag to the current source control branch. This supports using pact with feature branches. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.12&lt;/version&gt; &lt;configuration&gt; &lt;pactDirectory&gt;path/to/pact/files&lt;/pactDirectory&gt; &lt;!-- Defaults to ${project.build.directory}/pacts --&gt; &lt;pactBrokerUrl&gt;http://pactbroker:1234&lt;/pactBrokerUrl&gt; &lt;projectVersion&gt;1.0.100&lt;/projectVersion&gt; &lt;!-- Defaults to ${project.version} --&gt; &lt;tags&gt; &lt;tag&gt;feature/feature_name&lt;/tag&gt; &lt;/tags&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Publishing to an authenticated pact broker For an authenticated pact broker, you can pass in the credentials with the `pactBrokerUsername` and `pactBrokerPassword` properties. Currently it only supports basic authentication. For example: ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.11&lt;/version&gt; &lt;configuration&gt; &lt;pactBrokerUrl&gt;http://pactbroker:1234&lt;/pactBrokerUrl&gt; &lt;pactBrokerUsername&gt;USERNAME&lt;/pactBrokerUsername&gt; &lt;pactBrokerPassword&gt;PASSWORD&lt;/pactBrokerPassword&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` #### Using the Maven servers configuration [version 3.5.6+] From version 3.5.6, you can use the servers setup in the Maven settings. To do this, setup a server as per the [Maven Server Settings](https://maven.apache.org/settings.html#Servers). Then set the server ID in the pact broker configuration in your POM. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.11&lt;/artifactId&gt; &lt;version&gt;3.5.19&lt;/version&gt; &lt;configuration&gt; &lt;pactBrokerUrl&gt;http://pactbroker:1234&lt;/pactBrokerUrl&gt; &lt;pactBrokerServerId&gt;test-pact-broker&lt;/pactBrokerServerId&gt; &lt;!-- This must match the server id in the maven settings --&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` ## Excluding pacts from being published [version 3.5.19+] You can exclude some of the pact files from being published by providing a list of regular expressions that match against the base names of the pact files. For example: ```groovy pact { publish { pactBrokerUrl = &apos;https://mypactbroker.com&apos; excludes = [ &apos;.*\\-\\d+$&apos; ] // exclude all pact files that end with a dash followed by a number in the name } } ``` ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.19&lt;/version&gt; &lt;configuration&gt; &lt;pactBrokerUrl&gt;http://pactbroker:1234&lt;/pactBrokerUrl&gt; &lt;excludes&gt; &lt;exclude&gt;.*\\-\\d+$&lt;/exclude&gt; &lt;!-- exclude pact files where the name ends in a dash followed by a number --&gt; &lt;/excludes&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` # Publishing verification results to a Pact Broker [version 3.5.4+] For pacts that are loaded from a Pact Broker, the results of running the verification can be published back to the broker against the URL for the pact. You will be able to then see the result on the Pact Broker home screen. To turn on the verification publishing, set the system property `pact.verifier.publishResults` to `true` in the pact maven plugin, not surefire, configuration. # Enabling other verification reports [version 3.5.20+] By default the verification report is written to the console. You can also enable a JSON or Markdown report by setting the `reports` configuration list. ```xml &lt;plugin&gt; &lt;groupId&gt;au.com.dius&lt;/groupId&gt; &lt;artifactId&gt;pact-jvm-provider-maven_2.12&lt;/artifactId&gt; &lt;version&gt;3.5.20&lt;/version&gt; &lt;configuration&gt; &lt;reports&gt; &lt;report&gt;console&lt;/report&gt; &lt;report&gt;json&lt;/report&gt; &lt;report&gt;markdown&lt;/report&gt; &lt;/reports&gt; &lt;/configuration&gt; &lt;/plugin&gt; ``` These reports will be written to `target/reports/pact`.

Jvm interopability for Kovenant. Promises for Kotlin.