Download JAR files tagged by format with all dependencies

Show color codes preview per line in a sidebar area of an editor. <h2>Disable / Enable</h2> Check/Uncheck View > Show Colors <h2>Supported color patterns</h2> <ul> <li>Hex color code (e.g. #ffffff, #000)</li> <li>Css rgb/rgba values (e.g. rgb(0,0,0), rgba(255, 255, 255, 0.8))</li> <li>Css hsl/hsla values (e.g. hsl(0, 100%, 50%), hsla(120, 100%, 50%, 0.5))</li> <li>Named colors (e.g. red, blue)</li> <li>Java Color class (e.g. Color.black, new Color(100, 100, 100))</li> </ul> <h2>Multiple colors</h2> <ul> <li>Show top two colors in a sidebar if there are multiple colors in a line.</li> <li>If you want to check all colors, please click a specific rectangle. They will be shown as a list.</li> </ul> <h2>Change a color using the color chooser</h2> <ul> <li>Click a colored rectangle</li> <li>Click a color value of a list</li> <li>Select a new color in the color chooser</li> <li>An old color value will be changed to new one with the same format</li> </ul> <h2>Generate color codes</h2><p>You can generate color codes via a code generator(<kbd>Alt</kbd> + <kbd>Ins</kbd>).</p> <ol> <li>Run a code generator(Alt + Ins)</li> <li>Choose <code>Color...</code></li> <li>Choose format you expect (e.g. <code>new Color(r, g, b)</code>)</li> <li>Choose a color</li> <li>Click the OK button</li> <li>A color code is generated at the caret position</li> </ol> <h2>Options</h2> Tools > Options > Miscellaneous > Color Codes Preview <h3>Regex for enabled mime-types for Hex and CSS colors</h3> Default value is `^text/(x-)?(css|less|sass|scss)$`. If you would like to disable/enable some mime-types, please change the default regex. This pattern is used when the plugin checks a mime-type. <h3>Named Colors</h3> This option is `false` by default. If you would like to show named colors, please check it. <h2>NOTE</h2> <ul> <li>If you would like to show colors of `Color.decode(<hex>)` e.g. `Color.decode(#000000)`, Please add `java` to "Regex for enabled mime-types" of Hex and CSS e.g. (`^text/(x-)?(css|less|sass|scss|java)$`)</li> <li>Colors may be shown if they are not color codes. e.g. "#feature" contains #fea. This plugin recognizes it as a hex color code.</li> <li>If you use the GTK Look and Feel, you cannot change an alpha value in the color chooser.</li> <li>Hsl or hsla color values may not be changed correctly when you use the color chooser. (There may be 1% errors.)</li> </ul>

GroupDocs.Metadata for Java is a class library to process metadata associated with various Document, Image, CAD, Audio, Video and Archive formats. Key Features: - Covers most popular metadata standards: XMP, EXIF, IPTC, Image Resource Blocks, ID3, document properties - Covers most popular document formats: Microsoft Word, Microsoft Excel, Microsoft PowerPoint, PDF, Microsoft OneNote, Microsoft Visio, Open Document Format - Covers most popular image formats: BMP, GIF, DjVu, JPEG, PNG, TIFF, PSD, WebP, WMF, EMF, DICOM - Covers most popular email formats: Outlook Message, Email Message - Covers most popular audio formats: Mp3, WAV - Covers most popular video formats: Avi, Mov - Create, modify and remove metadata associated with supported document and image formats with a few lines of code - Manage EXIF metadata in Jpeg and TIFF formats - Manage XMP metadata in image and PDF formats - Manage Image Resource blocks in image formats - Manage audio metadata: ID3 tag (ID3v1, ID3v2), Lyrics3 tag, APE - Utilities to inspect and clean hidden metadata in document formats - Utilities to Search and Compare all metadata - Utilities to Export metadata to Excel/Csv - Metadata cleaner utility - MIME type detection - Read track changes. Accept or reject track changes - Read EXIF maker-notes: Sony, Nikon, Canon, Panasonic For more details on the library, please visit GroupDocs website at: https://products.groupdocs.com/metadata/Java Note: The library comes up with some limitations in the evaluation mode. In order to test full features of GroupDocs.Metadata for Java library, please request a free 30-day temporary license.

pact-jvm-consumer-groovy ========================= Groovy DSL for Pact JVM ##Dependency The library is available on maven central using: * group-id = `au.com.dius` * artifact-id = `pact-jvm-consumer-groovy_2.11` * version-id = `2.3.x` or `3.1.x` ##Usage Add the `pact-jvm-consumer-groovy` library to your test class path. This provides a `PactBuilder` class for you to use to define your pacts. For a full example, have a look at the example JUnit `ExampleGroovyConsumerPactTest`. If you are using gradle for your build, add it to your `build.gradle`: dependencies { testCompile 'au.com.dius:pact-jvm-consumer-groovy_2.11:3.1.0' } Then create an instance of the `PactBuilder` in your test. ```groovy @Test void "A service consumer side of a pact goes a little something like this"() { def alice_service = new PactBuilder() // Create a new PactBuilder alice_service { serviceConsumer "Consumer" // Define the service consumer by name hasPactWith "Alice Service" // Define the service provider that it has a pact with port 1234 // The port number for the service. It is optional, leave it out to // to use a random one given('there is some good mallory') // defines a provider state. It is optional. uponReceiving('a retrieve Mallory request') // upon_receiving starts a new interaction withAttributes(method: 'get', path: '/mallory') // define the request, a GET request to '/mallory' willRespondWith( // define the response we want returned status: 200, headers: ['Content-Type': 'text/html'], body: '"That is some good Mallory."' ) } // Execute the run method to have the mock server run. // It takes a closure to execute your requests and returns a Pact VerificationResult. VerificationResult result = alice_service.run() { def client = new RESTClient('http://localhost:1234/') def alice_response = client.get(path: '/mallory') assert alice_response.status == 200 assert alice_response.contentType == 'text/html' def data = alice_response.data.text() assert data == '"That is some good Mallory."' } assert result == PactVerified$.MODULE$ // This means it is all good in weird Scala speak. } ``` After running this test, the following pact file is produced: { "provider" : { "name" : "Alice Service" }, "consumer" : { "name" : "Consumer" }, "interactions" : [ { "provider_state" : "there is some good mallory", "description" : "a retrieve Mallory request", "request" : { "method" : "get", "path" : "/mallory", "requestMatchers" : { } }, "response" : { "status" : 200, "headers" : { "Content-Type" : "text/html" }, "body" : "That is some good Mallory.", "responseMatchers" : { } } } ] } ### DSL Methods #### serviceConsumer(String consumer) This names the service consumer for the pact. #### hasPactWith(String provider) This names the service provider for the pact. #### port(int port) Sets the port that the mock server will run on. If not supplied, a random port will be used. #### given(String providerState) Defines a state that the provider needs to be in for the request to succeed. For more info, see https://github.com/realestate-com-au/pact/wiki/Provider-states #### uponReceiving(String requestDescription) Starts the definition of a of a pact interaction. #### withAttributes(Map requestData) Defines the request for the interaction. The request data map can contain the following: | key | Description | Default Value | |----------------------------|-------------------------------------------|-----------------------------| | method | The HTTP method to use | get | | path | The Path for the request | / | | query | Query parameters as a Map<String, List> | | | headers | Map of key-value pairs for the request headers | | | body | The body of the request. If it is not a string, it will be converted to JSON. Also accepts a PactBodyBuilder. | | | prettyPrint | Boolean value to control if the body is pretty printed. See note on Pretty Printed Bodies below | For the path and header attributes (version 2.2.2+ for headers), you can use regular expressions to match. You can either provide a regex `Pattern` class or use the `regexp` method to construct a `RegexpMatcher` (you can use any of the defined matcher methods, see DSL methods below). If you use a `Pattern`, or the `regexp` method but don't provide a value, a random one will be generated from the regular expression. This value is used when generating requests. For example: ```groovy .withAttributes(path: ~'/transaction/[0-9]+') // This will generate a random path for requests // or .withAttributes(path: regexp('/transaction/[0-9]+', '/transaction/1234567890')) ``` #### withBody(Closure closure) Constructs the body of the request or response by invoking the supplied closure in the context of a PactBodyBuilder. ##### Pretty Printed Bodies [Version 2.2.15+, 3.0.4+] An optional Map can be supplied to control how the body is generated. The option values are available: | Option | Description | |--------|-------------| | mimeType | The mime type of the body. Defaults to `application/json` | | prettyPrint | Boolean value controlling whether to pretty-print the body or not. Defaults to true | If the prettyPrint option is not specified, the bodies will be pretty printed unless the mime type corresponds to one that requires compact bodies. Currently only `application/x-thrift+json` is classed as requiring a compact body. For an example of turning off pretty printing: ```groovy service { uponReceiving('a request') withAttributes(method: 'get', path: '/') withBody(prettyPrint: false) { name 'harry' surname 'larry' } } ``` #### willRespondWith(Map responseData) Defines the response for the interaction. The response data map can contain the following: | key | Description | Default Value | |----------------------------|-------------------------------------------|-----------------------------| | status | The HTTP status code to return | 200 | | headers | Map of key-value pairs for the response headers | | | body | The body of the response. If it is not a string, it will be converted to JSON. Also accepts a PactBodyBuilder. | | | prettyPrint | Boolean value to control if the body is pretty printed. See note on Pretty Printed Bodies above | For the headers (version 2.2.2+), you can use regular expressions to match. You can either provide a regex `Pattern` class or use the `regexp` method to construct a `RegexpMatcher` (you can use any of the defined matcher methods, see DSL methods below). If you use a `Pattern`, or the `regexp` method but don't provide a value, a random one will be generated from the regular expression. This value is used when generating responses. For example: ```groovy .willRespondWith(headers: [LOCATION: ~'/transaction/[0-9]+']) // This will generate a random location value // or .willRespondWith(headers: [LOCATION: regexp('/transaction/[0-9]+', '/transaction/1234567890')]) ``` #### VerificationResult run(Closure closure) The `run` method starts the mock server, and then executes the provided closure. It then returns the pact verification result for the pact run. If you require access to the mock server configuration for the URL, it is passed into the closure, e.g., ```groovy VerificationResult result = alice_service.run() { config -> def client = new RESTClient(config.url()) def alice_response = client.get(path: '/mallory') } ``` ### Body DSL For building JSON bodies there is a `PactBodyBuilder` that provides as DSL that includes matching with regular expressions and by types. For a more complete example look at `PactBodyBuilderTest`. For an example: ```groovy service { uponReceiving('a request') withAttributes(method: 'get', path: '/') withBody { name(~/\w+/, 'harry') surname regexp(~/\w+/, 'larry') position regexp(~/staff|contractor/, 'staff') happy(true) } } ``` This will return the following body: ```json { "name": "harry", "surname": "larry", "position": "staff", "happy": true } ``` and add the following matchers: ```json { "$.body.name": {"regex": "\\w+"}, "$.body.surname": {"regex": "\\w+"}, "$.body.position": {"regex": "staff|contractor"} } ``` #### DSL Methods The DSL supports the following matching methods: * regexp(Pattern re, String value = null), regexp(String regexp, String value = null) Defines a regular expression matcher. If the value is not provided, a random one will be generated. * hexValue(String value = null) Defines a matcher that accepts hexidecimal values. If the value is not provided, a random hexidcimal value will be generated. * identifier(def value = null) Defines a matcher that accepts integer values. If the value is not provided, a random value will be generated. * ipAddress(String value = null) Defines a matcher that accepts IP addresses. If the value is not provided, a 127.0.0.1 will be used. * numeric(Number value = null) Defines a matcher that accepts any numerical values. If the value is not provided, a random integer will be used. * integer(def value = null) Defines a matcher that accepts any integer values. If the value is not provided, a random integer will be used. * real(def value = null) Defines a matcher that accepts any real numbers. If the value is not provided, a random double will be used. * timestamp(String pattern = null, def value = null) If pattern is not provided the ISO_DATETIME_FORMAT is used ("yyyy-MM-dd'T'HH:mm:ss") . If the value is not provided, the current date and time is used. * time(String pattern = null, def value = null) If pattern is not provided the ISO_TIME_FORMAT is used ("'T'HH:mm:ss") . If the value is not provided, the current date and time is used. * date(String pattern = null, def value = null) If pattern is not provided the ISO_DATE_FORMAT is used ("yyyy-MM-dd") . If the value is not provided, the current date and time is used. * uuid(String value = null) Defines a matcher that accepts UUIDs. A random one will be generated if no value is provided. #### What if a field matches a matcher name in the DSL? When using the body DSL, if there is a field that matches a matcher name (e.g. a field named 'date') then you can do the following: ```groovy withBody { date = date() } ``` ### 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 `eachLike`, `minLike` and `maxLike` functions. | function | description | |----------|-------------| | `eachLike()` | Ensure that each item in the list matches the provided example | | `maxLike(integer max)` | Ensure that each item in the list matches the provided example and the list is no bigger than the provided max | | `minLike(integer min)` | Ensure that each item in the list matches the provided example and the list is no smaller than the provided min | For example: ```groovy withBody { users minLike(1) { id identifier name string('Fred') } } ``` This will ensure that the user 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. ```groovy withBody { users minLike(1, 3) { id identifier name string('Fred') } } ``` This will create an example user list with 3 users. ## 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" } ``` # 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 pass an option into the `run` method. For example: ```groovy VerificationResult result = service.run(specificationVersion: PactSpecVersion.V3) { config -> def client = new RESTClient(config.url()) def response = client.get(path: '/') } ``` ## Consumer test for a message consumer For testing a consumer of messages from a message queue, the `PactMessageBuilder` class provides a DSL for defining your message expectations. It works in much the same way as the `PactBuilder` class for Request-Response interactions, but will generate a V3 format message pact file. The following steps demonstrate how to use it. ### Step 1 - define the message expectations Create a test that uses the `PactMessageBuilder` to define a message expectation, and then call `run`. This will invoke the given closure with a message for each one defined in the pact. ```groovy def eventStream = new PactMessageBuilder().call { serviceConsumer 'messageConsumer' hasPactWith 'messageProducer' given 'order with id 10000004 exists' expectsToReceive 'an order confirmation message' withMetaData(type: 'OrderConfirmed') // Can define any key-value pairs here withContent(contentType: 'application/json') { type 'OrderConfirmed' audit { userCode 'messageService' } origin 'message-service' referenceId '10000004-2' timeSent: '2015-07-22T10:14:28+00:00' value { orderId '10000004' value '10.000000' fee '10.00' gst '15.00' } } } ``` ### Step 2 - call your message handler with the generated messages This example tests a message handler that gets messages from a Kafka topic. In this case the Pact message is wrapped as a Kafka `MessageAndMetadata`. ```groovy eventStream.run { Message message -> messageHandler.handleMessage(new MessageAndMetadata('topic', 1, new kafka.message.Message(message.contentsAsBytes()), 0, null, valueDecoder)) } ``` ### Step 3 - validate that the message was handled correctly ```groovy def order = orderRepository.getOrder('10000004') assert order.status == 'confirmed' assert order.value == 10.0 ``` ### Step 4 - Publish the pact file If the test was successful, a pact file would have been produced with the message from step 1.

pact-jvm-consumer-groovy ========================= Groovy DSL for Pact JVM ## Dependency The library is available on maven central using: * group-id = `au.com.dius` * artifact-id = `pact-jvm-consumer-groovy_2.11` * version-id = `3.5.x` ## Usage Add the `pact-jvm-consumer-groovy` library to your test class path. This provides a `PactBuilder` class for you to use to define your pacts. For a full example, have a look at the example JUnit `ExampleGroovyConsumerPactTest`. If you are using gradle for your build, add it to your `build.gradle`: dependencies { testCompile &apos;au.com.dius:pact-jvm-consumer-groovy_2.11:3.5.0&apos; } Then create an instance of the `PactBuilder` in your test. ```groovy import au.com.dius.pact.consumer.PactVerificationResult import au.com.dius.pact.consumer.groovy.PactBuilder import groovyx.net.http.RESTClient import org.junit.Test class AliceServiceConsumerPactTest { @Test void &quot;A service consumer side of a pact goes a little something like this&quot;() { def alice_service = new PactBuilder() // Create a new PactBuilder alice_service { serviceConsumer &quot;Consumer&quot; // Define the service consumer by name hasPactWith &quot;Alice Service&quot; // Define the service provider that it has a pact with port 1234 // The port number for the service. It is optional, leave it out to // to use a random one given(&apos;there is some good mallory&apos;) // defines a provider state. It is optional. uponReceiving(&apos;a retrieve Mallory request&apos;) // upon_receiving starts a new interaction withAttributes(method: &apos;get&apos;, path: &apos;/mallory&apos;) // define the request, a GET request to &apos;/mallory&apos; willRespondWith( // define the response we want returned status: 200, headers: [&apos;Content-Type&apos;: &apos;text/html&apos;], body: &apos;&quot;That is some good Mallory.&quot;&apos; ) } // Execute the run method to have the mock server run. // It takes a closure to execute your requests and returns a PactVerificationResult. PactVerificationResult result = alice_service.runTest { def client = new RESTClient(&apos;http://localhost:1234/&apos;) def alice_response = client.get(path: &apos;/mallory&apos;) assert alice_response.status == 200 assert alice_response.contentType == &apos;text/html&apos; def data = alice_response.data.text() assert data == &apos;&quot;That is some good Mallory.&quot;&apos; } assert result == PactVerificationResult.Ok.INSTANCE // This means it is all good } } ``` After running this test, the following pact file is produced: { &quot;provider&quot; : { &quot;name&quot; : &quot;Alice Service&quot; }, &quot;consumer&quot; : { &quot;name&quot; : &quot;Consumer&quot; }, &quot;interactions&quot; : [ { &quot;provider_state&quot; : &quot;there is some good mallory&quot;, &quot;description&quot; : &quot;a retrieve Mallory request&quot;, &quot;request&quot; : { &quot;method&quot; : &quot;get&quot;, &quot;path&quot; : &quot;/mallory&quot;, &quot;requestMatchers&quot; : { } }, &quot;response&quot; : { &quot;status&quot; : 200, &quot;headers&quot; : { &quot;Content-Type&quot; : &quot;text/html&quot; }, &quot;body&quot; : &quot;That is some good Mallory.&quot;, &quot;responseMatchers&quot; : { } } } ] } ### DSL Methods #### serviceConsumer(String consumer) This names the service consumer for the pact. #### hasPactWith(String provider) This names the service provider for the pact. #### port(int port) Sets the port that the mock server will run on. If not supplied, a random port will be used. #### given(String providerState) Defines a state that the provider needs to be in for the request to succeed. For more info, see https://github.com/realestate-com-au/pact/wiki/Provider-states. Can be called multiple times. #### given(String providerState, Map params) Defines a state that the provider needs to be in for the request to succeed. For more info, see https://github.com/realestate-com-au/pact/wiki/Provider-states. Can be called multiple times, and the params map can contain the data required for the state. #### uponReceiving(String requestDescription) Starts the definition of a of a pact interaction. #### withAttributes(Map requestData) Defines the request for the interaction. The request data map can contain the following: | key | Description | Default Value | |----------------------------|-------------------------------------------|-----------------------------| | method | The HTTP method to use | get | | path | The Path for the request | / | | query | Query parameters as a Map&lt;String, List&gt; | | | headers | Map of key-value pairs for the request headers | | | body | The body of the request. If it is not a string, it will be converted to JSON. Also accepts a PactBodyBuilder. | | | prettyPrint | Boolean value to control if the body is pretty printed. See note on Pretty Printed Bodies below | For the path, header attributes and query parameters (version 2.2.2+ for headers, 3.3.7+ for query parameters), you can use regular expressions to match. You can either provide a regex `Pattern` class or use the `regexp` method to construct a `RegexpMatcher` (you can use any of the defined matcher methods, see DSL methods below). If you use a `Pattern`, or the `regexp` method but don&apos;t provide a value, a random one will be generated from the regular expression. This value is used when generating requests. For example: ```groovy .withAttributes(path: ~&apos;/transaction/[0-9]+&apos;) // This will generate a random path for requests // or .withAttributes(path: regexp(&apos;/transaction/[0-9]+&apos;, &apos;/transaction/1234567890&apos;)) ``` #### withBody(Closure closure) Constructs the body of the request or response by invoking the supplied closure in the context of a PactBodyBuilder. ##### Pretty Printed Bodies [Version 2.2.15+, 3.0.4+] An optional Map can be supplied to control how the body is generated. The option values are available: | Option | Description | |--------|-------------| | mimeType | The mime type of the body. Defaults to `application/json` | | prettyPrint | Boolean value controlling whether to pretty-print the body or not. Defaults to true | If the prettyPrint option is not specified, the bodies will be pretty printed unless the mime type corresponds to one that requires compact bodies. Currently only `application/x-thrift+json` is classed as requiring a compact body. For an example of turning off pretty printing: ```groovy service { uponReceiving(&apos;a request&apos;) withAttributes(method: &apos;get&apos;, path: &apos;/&apos;) withBody(prettyPrint: false) { name &apos;harry&apos; surname &apos;larry&apos; } } ``` #### willRespondWith(Map responseData) Defines the response for the interaction. The response data map can contain the following: | key | Description | Default Value | |----------------------------|-------------------------------------------|-----------------------------| | status | The HTTP status code to return | 200 | | headers | Map of key-value pairs for the response headers | | | body | The body of the response. If it is not a string, it will be converted to JSON. Also accepts a PactBodyBuilder. | | | prettyPrint | Boolean value to control if the body is pretty printed. See note on Pretty Printed Bodies above | For the headers (version 2.2.2+), you can use regular expressions to match. You can either provide a regex `Pattern` class or use the `regexp` method to construct a `RegexpMatcher` (you can use any of the defined matcher methods, see DSL methods below). If you use a `Pattern`, or the `regexp` method but don&apos;t provide a value, a random one will be generated from the regular expression. This value is used when generating responses. For example: ```groovy .willRespondWith(headers: [LOCATION: ~&apos;/transaction/[0-9]+&apos;]) // This will generate a random location value // or .willRespondWith(headers: [LOCATION: regexp(&apos;/transaction/[0-9]+&apos;, &apos;/transaction/1234567890&apos;)]) ``` #### PactVerificationResult runTest(Closure closure) The `runTest` method starts the mock server, and then executes the provided closure. It then returns the pact verification result for the pact run. If you require access to the mock server configuration for the URL, it is passed into the closure, e.g., ```groovy PactVerificationResult result = alice_service.runTest() { mockServer -&gt; def client = new RESTClient(mockServer.url) def alice_response = client.get(path: &apos;/mallory&apos;) } ``` ### Note on HTTP clients and persistent connections Some HTTP clients may keep the connection open, based on the live connections settings or if they use a connection cache. This could cause your tests to fail if the client you are testing lives longer than an individual test, as the mock server will be started and shutdown for each test. This will result in the HTTP client connection cache having invalid connections. For an example of this where the there was a failure for every second test, see [Issue #342](https://github.com/DiUS/pact-jvm/issues/342). ### Body DSL For building JSON bodies there is a `PactBodyBuilder` that provides as DSL that includes matching with regular expressions and by types. For a more complete example look at `PactBodyBuilderTest`. For an example: ```groovy service { uponReceiving(&apos;a request&apos;) withAttributes(method: &apos;get&apos;, path: &apos;/&apos;) withBody { name(~/\w+/, &apos;harry&apos;) surname regexp(~/\w+/, &apos;larry&apos;) position regexp(~/staff|contractor/, &apos;staff&apos;) happy(true) } } ``` This will return the following body: ```json { &quot;name&quot;: &quot;harry&quot;, &quot;surname&quot;: &quot;larry&quot;, &quot;position&quot;: &quot;staff&quot;, &quot;happy&quot;: true } ``` and add the following matchers: ```json { &quot;$.body.name&quot;: {&quot;regex&quot;: &quot;\\w+&quot;}, &quot;$.body.surname&quot;: {&quot;regex&quot;: &quot;\\w+&quot;}, &quot;$.body.position&quot;: {&quot;regex&quot;: &quot;staff|contractor&quot;} } ``` #### DSL Methods The DSL supports the following matching methods: * regexp(Pattern re, String value = null), regexp(String regexp, String value = null) Defines a regular expression matcher. If the value is not provided, a random one will be generated. * hexValue(String value = null) Defines a matcher that accepts hexidecimal values. If the value is not provided, a random hexidcimal value will be generated. * identifier(def value = null) Defines a matcher that accepts integer values. If the value is not provided, a random value will be generated. * ipAddress(String value = null) Defines a matcher that accepts IP addresses. If the value is not provided, a 127.0.0.1 will be used. * numeric(Number value = null) Defines a matcher that accepts any numerical values. If the value is not provided, a random integer will be used. * integer(def value = null) Defines a matcher that accepts any integer values. If the value is not provided, a random integer will be used. * decimal(def value = null) Defines a matcher that accepts any decimal numbers. If the value is not provided, a random decimal will be used. * timestamp(String pattern = null, def value = null) If pattern is not provided the ISO_DATETIME_FORMAT is used (&quot;yyyy-MM-dd&apos;T&apos;HH:mm:ss&quot;) . If the value is not provided, the current date and time is used. * time(String pattern = null, def value = null) If pattern is not provided the ISO_TIME_FORMAT is used (&quot;&apos;T&apos;HH:mm:ss&quot;) . If the value is not provided, the current date and time is used. * date(String pattern = null, def value = null) If pattern is not provided the ISO_DATE_FORMAT is used (&quot;yyyy-MM-dd&quot;) . If the value is not provided, the current date and time is used. * uuid(String value = null) Defines a matcher that accepts UUIDs. A random one will be generated if no value is provided. * equalTo(def value) Defines an equality matcher that always matches the provided value using `equals`. This is useful for resetting cascading type matchers. * includesStr(def value) Defines a matcher that accepts any value where its string form includes the provided string. * nullValue() Defines a matcher that accepts only null values. * url(String basePath, Object... pathFragments) Defines a matcher for URLs, given the base URL path and a sequence of path fragments. The path fragments could be strings or regular expression matchers. For example: ```groovy url(&apos;http://localhost:8080&apos;, &apos;pacticipants&apos;, regexp(&apos;[^\\/]+&apos;, &apos;Activity%20Service&apos;)) ``` Defines a matcher that accepts only null values. #### What if a field matches a matcher name in the DSL? When using the body DSL, if there is a field that matches a matcher name (e.g. a field named &apos;date&apos;) then you can do the following: ```groovy withBody { date = date() } ``` ### 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 `eachLike`, `minLike` and `maxLike` functions. | function | description | |----------|-------------| | `eachLike()` | Ensure that each item in the list matches the provided example | | `maxLike(integer max)` | Ensure that each item in the list matches the provided example and the list is no bigger than the provided max | | `minLike(integer min)` | Ensure that each item in the list matches the provided example and the list is no smaller than the provided min | For example: ```groovy withBody { users minLike(1) { id identifier name string(&apos;Fred&apos;) } } ``` This will ensure that the user 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. ```groovy withBody { users minLike(1, 3) { id identifier name string(&apos;Fred&apos;) } } ``` This will create an example user list with 3 users. __Version 3.2.13/2.4.14+__ The each like matchers have been updated to work with primitive types. ```groovy withBody { permissions eachLike(3, &apos;GRANT&apos;) } ``` will generate the following JSON ```json { &quot;permissions&quot;: [&quot;GRANT&quot;, &quot;GRANT&quot;, &quot;GRANT&quot;] } ``` and matchers ```json { &quot;$.body.permissions&quot;: {&quot;match&quot;: &quot;type&quot;} } ``` and now you can even get more fancy ```groovy withBody { permissions eachLike(3, regexp(~/\w+/)) permissions2 minLike(2, 3, integer()) permissions3 maxLike(4, 3, ~/\d+/) } ``` You can also match arrays at the root level, for instance, ```groovy withBody PactBodyBuilder.eachLike(regexp(~/\w+/)) ``` or if you have arrays of arrays ```groovy withBody PactBodyBuilder.eachLike([ regexp(&apos;[0-9a-f]{8}&apos;, &apos;e8cda07e&apos;), regexp(~/\w+/, &apos;sony&apos;) ]) ``` __Version 3.5.9+__ A `eachArrayLike` method has been added to handle matching of arrays of arrays. ```groovy { answers minLike(1) { questionId string(&quot;books&quot;) answer eachArrayLike { questionId string(&quot;title&quot;) answer string(&quot;BBBB&quot;) } } ``` This will generate an array of arrays for the `answer` attribute. ### 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 `keyLike` method, which takes an example key as a parameter. For example: ```groovy withBody { example { one { keyLike &apos;001&apos;, &apos;value&apos; // key like an id mapped to a value } two { keyLike &apos;ABC001&apos;, regexp(&apos;\\w+&apos;) // key like an id mapped to a matcher } three { keyLike &apos;XYZ001&apos;, { // key like an id mapped to a closure id identifier() } } four { keyLike &apos;001XYZ&apos;, eachLike { // key like an id mapped to an array where each item is matched by the following id identifier() // example } } } } ``` For an example, have a look at [WildcardPactSpec](src/test/au/com/dius/pact/consumer/groovy/WildcardPactSpec.groovy). **NOTE:** The `keyLike` 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 `keyLike` condition applied to a map will result in only one being applied when the pact is verified (probably the last). **Further Note: From version 3.5.22 onwards pacts with wildcards applied to map keys will require the Java system property &quot;pact.matching.wildcard&quot; set to value &quot;true&quot; when the pact file is verified.** ### Matching with an OR (3.5.0+) The V3 spec allows multiple matchers to be combined using either AND or OR for a value. The main use of this would be to either be able to match a value or a null, or to combine different matchers. For example: ```groovy withBody { valueA and(&apos;AB&apos;, includeStr(&apos;A&apos;), includeStr(&apos;B&apos;)) // valueA must include both A and B valueB or(&apos;100&apos;, regex(~/\d+/), nullValue()) // valueB must either match a regular expression or be null valueC or(&apos;12345678&apos;, regex(~/\d{8}/), regex(~/X\d{13}/)) // valueC must match either 8 or X followed by 13 digits } ``` ## Changing the directory pact files are written to (2.1.9+) By default, pact files are written to `target/pacts` (or `build/pacts` if you use Gradle), 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[&apos;pact.rootDir&apos;] = &quot;$buildDir/custom-pacts-directory&quot; } ``` ## Forcing pact files to be overwritten (3.6.5+) By default, when the pact file is written, it will be merged with any existing pact file. To force the file to be overwritten, set the Java system property `pact.writer.overwrite` to `true`. # 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/provider/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. * Multiple provider states can be defined with data parameters. ## Generating V3 spec pact files (3.1.0+, 2.3.0+) To have your consumer tests generate V3 format pacts, you can pass an option into the `runTest` method. For example: ```groovy PactVerificationResult result = service.runTest(specificationVersion: PactSpecVersion.V3) { config -&gt; def client = new RESTClient(config.url) def response = client.get(path: &apos;/&apos;) } ``` ## Consumer test for a message consumer For testing a consumer of messages from a message queue, the `PactMessageBuilder` class provides a DSL for defining your message expectations. It works in much the same way as the `PactBuilder` class for Request-Response interactions, but will generate a V3 format message pact file. The following steps demonstrate how to use it. ### Step 1 - define the message expectations Create a test that uses the `PactMessageBuilder` to define a message expectation, and then call `run`. This will invoke the given closure with a message for each one defined in the pact. ```groovy def eventStream = new PactMessageBuilder().call { serviceConsumer &apos;messageConsumer&apos; hasPactWith &apos;messageProducer&apos; given &apos;order with id 10000004 exists&apos; expectsToReceive &apos;an order confirmation message&apos; withMetaData(type: &apos;OrderConfirmed&apos;) // Can define any key-value pairs here withContent(contentType: &apos;application/json&apos;) { type &apos;OrderConfirmed&apos; audit { userCode &apos;messageService&apos; } origin &apos;message-service&apos; referenceId &apos;10000004-2&apos; timeSent: &apos;2015-07-22T10:14:28+00:00&apos; value { orderId &apos;10000004&apos; value &apos;10.000000&apos; fee &apos;10.00&apos; gst &apos;15.00&apos; } } } ``` ### Step 2 - call your message handler with the generated messages This example tests a message handler that gets messages from a Kafka topic. In this case the Pact message is wrapped as a Kafka `MessageAndMetadata`. ```groovy eventStream.run { Message message -&gt; messageHandler.handleMessage(new MessageAndMetadata(&apos;topic&apos;, 1, new kafka.message.Message(message.contentsAsBytes()), 0, null, valueDecoder)) } ``` ### Step 3 - validate that the message was handled correctly ```groovy def order = orderRepository.getOrder(&apos;10000004&apos;) assert order.status == &apos;confirmed&apos; assert order.value == 10.0 ``` ### Step 4 - Publish the pact file If the test was successful, a pact file would have been produced with the message from step 1. # Having values injected from provider state callbacks (3.6.11+) You can have values from the provider state callbacks be injected into most places (paths, query parameters, headers, bodies, etc.). This works by using the V3 spec generators with provider state callbacks that return values. One example of where this would be useful is API calls that require an ID which would be auto-generated by the database on the provider side, so there is no way to know what the ID would be beforehand. The DSL method `fromProviderState` allows you to set an expression that will be parsed with the values returned from the provider states. For the body, you can use the key value instead of an expression. For example, assume that an API call is made to get the details of a user by ID. A provider state can be defined that specifies that the user must be exist, but the ID will be created when the user is created. So we can then define an expression for the path where the ID will be replaced with the value returned from the provider state callback. ```groovy service { given(&apos;User harry exists&apos;) uponReceiving(&apos;a request for user harry&apos;) withAttributes(method: &apos;get&apos;, path: fromProviderState(&apos;/api/user/${id}&apos;, &apos;/api/user/100&apos;)) withBody { name(fromProviderState(&apos;userName&apos;, &apos;harry&apos;)) // looks up the value using the userName key } } ```

pact-jvm-consumer-groovy ========================= Groovy DSL for Pact JVM ## Dependency The library is available on maven central using: * group-id = `au.com.dius` * artifact-id = `pact-jvm-consumer-groovy` * version-id = `4.0.x` ## Usage Add the `pact-jvm-consumer-groovy` library to your test class path. This provides a `PactBuilder` class for you to use to define your pacts. For a full example, have a look at the example JUnit `ExampleGroovyConsumerPactTest`. If you are using gradle for your build, add it to your `build.gradle`: dependencies { testCompile &apos;au.com.dius:pact-jvm-consumer-groovy:4.0.0&apos; } Then create an instance of the `PactBuilder` in your test. ```groovy import au.com.dius.pact.consumer.PactVerificationResult import au.com.dius.pact.consumer.groovy.PactBuilder import groovyx.net.http.RESTClient import org.junit.Test class AliceServiceConsumerPactTest { @Test void &quot;A service consumer side of a pact goes a little something like this&quot;() { def alice_service = new PactBuilder() // Create a new PactBuilder alice_service { serviceConsumer &quot;Consumer&quot; // Define the service consumer by name hasPactWith &quot;Alice Service&quot; // Define the service provider that it has a pact with port 1234 // The port number for the service. It is optional, leave it out to // to use a random one given(&apos;there is some good mallory&apos;) // defines a provider state. It is optional. uponReceiving(&apos;a retrieve Mallory request&apos;) // upon_receiving starts a new interaction withAttributes(method: &apos;get&apos;, path: &apos;/mallory&apos;) // define the request, a GET request to &apos;/mallory&apos; willRespondWith( // define the response we want returned status: 200, headers: [&apos;Content-Type&apos;: &apos;text/html&apos;], body: &apos;&quot;That is some good Mallory.&quot;&apos; ) } // Execute the run method to have the mock server run. // It takes a closure to execute your requests and returns a PactVerificationResult. PactVerificationResult result = alice_service.runTest { def client = new RESTClient(&apos;http://localhost:1234/&apos;) def alice_response = client.get(path: &apos;/mallory&apos;) assert alice_response.status == 200 assert alice_response.contentType == &apos;text/html&apos; def data = alice_response.data.text() assert data == &apos;&quot;That is some good Mallory.&quot;&apos; } assert result == PactVerificationResult.Ok.INSTANCE // This means it is all good } } ``` After running this test, the following pact file is produced: { &quot;provider&quot; : { &quot;name&quot; : &quot;Alice Service&quot; }, &quot;consumer&quot; : { &quot;name&quot; : &quot;Consumer&quot; }, &quot;interactions&quot; : [ { &quot;provider_state&quot; : &quot;there is some good mallory&quot;, &quot;description&quot; : &quot;a retrieve Mallory request&quot;, &quot;request&quot; : { &quot;method&quot; : &quot;get&quot;, &quot;path&quot; : &quot;/mallory&quot;, &quot;requestMatchers&quot; : { } }, &quot;response&quot; : { &quot;status&quot; : 200, &quot;headers&quot; : { &quot;Content-Type&quot; : &quot;text/html&quot; }, &quot;body&quot; : &quot;That is some good Mallory.&quot;, &quot;responseMatchers&quot; : { } } } ] } ### DSL Methods #### serviceConsumer(String consumer) This names the service consumer for the pact. #### hasPactWith(String provider) This names the service provider for the pact. #### port(int port) Sets the port that the mock server will run on. If not supplied, a random port will be used. #### given(String providerState) Defines a state that the provider needs to be in for the request to succeed. For more info, see https://github.com/realestate-com-au/pact/wiki/Provider-states. Can be called multiple times. #### given(String providerState, Map params) Defines a state that the provider needs to be in for the request to succeed. For more info, see https://github.com/realestate-com-au/pact/wiki/Provider-states. Can be called multiple times, and the params map can contain the data required for the state. #### uponReceiving(String requestDescription) Starts the definition of a of a pact interaction. #### withAttributes(Map requestData) Defines the request for the interaction. The request data map can contain the following: | key | Description | Default Value | |----------------------------|-------------------------------------------|-----------------------------| | method | The HTTP method to use | get | | path | The Path for the request | / | | query | Query parameters as a Map&lt;String, List&gt; | | | headers | Map of key-value pairs for the request headers | | | body | The body of the request. If it is not a string, it will be converted to JSON. Also accepts a PactBodyBuilder. | | | prettyPrint | Boolean value to control if the body is pretty printed. See note on Pretty Printed Bodies below | For the path, header attributes and query parameters (version 2.2.2+ for headers, 3.3.7+ for query parameters), you can use regular expressions to match. You can either provide a regex `Pattern` class or use the `regexp` method to construct a `RegexpMatcher` (you can use any of the defined matcher methods, see DSL methods below). If you use a `Pattern`, or the `regexp` method but don&apos;t provide a value, a random one will be generated from the regular expression. This value is used when generating requests. For example: ```groovy .withAttributes(path: ~&apos;/transaction/[0-9]+&apos;) // This will generate a random path for requests // or .withAttributes(path: regexp(&apos;/transaction/[0-9]+&apos;, &apos;/transaction/1234567890&apos;)) ``` #### withBody(Closure closure) Constructs the body of the request or response by invoking the supplied closure in the context of a PactBodyBuilder. ##### Pretty Printed Bodies An optional Map can be supplied to control how the body is generated. The option values are available: | Option | Description | |--------|-------------| | mimeType | The mime type of the body. Defaults to `application/json` | | prettyPrint | Boolean value controlling whether to pretty-print the body or not. Defaults to true | If the prettyPrint option is not specified, the bodies will be pretty printed unless the mime type corresponds to one that requires compact bodies. Currently only `application/x-thrift+json` is classed as requiring a compact body. For an example of turning off pretty printing: ```groovy service { uponReceiving(&apos;a request&apos;) withAttributes(method: &apos;get&apos;, path: &apos;/&apos;) withBody(prettyPrint: false) { name &apos;harry&apos; surname &apos;larry&apos; } } ``` #### willRespondWith(Map responseData) Defines the response for the interaction. The response data map can contain the following: | key | Description | Default Value | |----------------------------|-------------------------------------------|-----------------------------| | status | The HTTP status code to return | 200 | | headers | Map of key-value pairs for the response headers | | | body | The body of the response. If it is not a string, it will be converted to JSON. Also accepts a PactBodyBuilder. | | | prettyPrint | Boolean value to control if the body is pretty printed. See note on Pretty Printed Bodies above | For the headers (version 2.2.2+), you can use regular expressions to match. You can either provide a regex `Pattern` class or use the `regexp` method to construct a `RegexpMatcher` (you can use any of the defined matcher methods, see DSL methods below). If you use a `Pattern`, or the `regexp` method but don&apos;t provide a value, a random one will be generated from the regular expression. This value is used when generating responses. For example: ```groovy .willRespondWith(headers: [LOCATION: ~&apos;/transaction/[0-9]+&apos;]) // This will generate a random location value // or .willRespondWith(headers: [LOCATION: regexp(&apos;/transaction/[0-9]+&apos;, &apos;/transaction/1234567890&apos;)]) ``` #### PactVerificationResult runTest(Closure closure) The `runTest` method starts the mock server, and then executes the provided closure. It then returns the pact verification result for the pact run. If you require access to the mock server configuration for the URL, it is passed into the closure, e.g., ```groovy PactVerificationResult result = alice_service.runTest() { mockServer -&gt; def client = new RESTClient(mockServer.url) def alice_response = client.get(path: &apos;/mallory&apos;) } ``` ### Note on HTTP clients and persistent connections Some HTTP clients may keep the connection open, based on the live connections settings or if they use a connection cache. This could cause your tests to fail if the client you are testing lives longer than an individual test, as the mock server will be started and shutdown for each test. This will result in the HTTP client connection cache having invalid connections. For an example of this where the there was a failure for every second test, see [Issue #342](https://github.com/DiUS/pact-jvm/issues/342). ### Body DSL For building JSON bodies there is a `PactBodyBuilder` that provides as DSL that includes matching with regular expressions and by types. For a more complete example look at `PactBodyBuilderTest`. For an example: ```groovy service { uponReceiving(&apos;a request&apos;) withAttributes(method: &apos;get&apos;, path: &apos;/&apos;) withBody { name(~/\w+/, &apos;harry&apos;) surname regexp(~/\w+/, &apos;larry&apos;) position regexp(~/staff|contractor/, &apos;staff&apos;) happy(true) } } ``` This will return the following body: ```json { &quot;name&quot;: &quot;harry&quot;, &quot;surname&quot;: &quot;larry&quot;, &quot;position&quot;: &quot;staff&quot;, &quot;happy&quot;: true } ``` and add the following matchers: ```json { &quot;$.body.name&quot;: {&quot;regex&quot;: &quot;\\w+&quot;}, &quot;$.body.surname&quot;: {&quot;regex&quot;: &quot;\\w+&quot;}, &quot;$.body.position&quot;: {&quot;regex&quot;: &quot;staff|contractor&quot;} } ``` #### DSL Methods The DSL supports the following matching methods: * regexp(Pattern re, String value = null), regexp(String regexp, String value = null) Defines a regular expression matcher. If the value is not provided, a random one will be generated. * hexValue(String value = null) Defines a matcher that accepts hexidecimal values. If the value is not provided, a random hexidcimal value will be generated. * identifier(def value = null) Defines a matcher that accepts integer values. If the value is not provided, a random value will be generated. * ipAddress(String value = null) Defines a matcher that accepts IP addresses. If the value is not provided, a 127.0.0.1 will be used. * numeric(Number value = null) Defines a matcher that accepts any numerical values. If the value is not provided, a random integer will be used. * integer(def value = null) Defines a matcher that accepts any integer values. If the value is not provided, a random integer will be used. * decimal(def value = null) Defines a matcher that accepts any decimal numbers. If the value is not provided, a random decimal will be used. * timestamp(String pattern = null, def value = null) If pattern is not provided the ISO_DATETIME_FORMAT is used (&quot;yyyy-MM-dd&apos;T&apos;HH:mm:ss&quot;) . If the value is not provided, the current date and time is used. * time(String pattern = null, def value = null) If pattern is not provided the ISO_TIME_FORMAT is used (&quot;&apos;T&apos;HH:mm:ss&quot;) . If the value is not provided, the current date and time is used. * date(String pattern = null, def value = null) If pattern is not provided the ISO_DATE_FORMAT is used (&quot;yyyy-MM-dd&quot;) . If the value is not provided, the current date and time is used. * uuid(String value = null) Defines a matcher that accepts UUIDs. A random one will be generated if no value is provided. * equalTo(def value) Defines an equality matcher that always matches the provided value using `equals`. This is useful for resetting cascading type matchers. * includesStr(def value) Defines a matcher that accepts any value where its string form includes the provided string. * nullValue() Defines a matcher that accepts only null values. * url(String basePath, Object... pathFragments) Defines a matcher for URLs, given the base URL path and a sequence of path fragments. The path fragments could be strings or regular expression matchers. For example: ```groovy url(&apos;http://localhost:8080&apos;, &apos;pacticipants&apos;, regexp(&apos;[^\\/]+&apos;, &apos;Activity%20Service&apos;)) ``` Defines a matcher that accepts only null values. #### What if a field matches a matcher name in the DSL? When using the body DSL, if there is a field that matches a matcher name (e.g. a field named &apos;date&apos;) then you can do the following: ```groovy withBody { date = date() } ``` ### Ensuring all items in a list match an example 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 `eachLike`, `minLike` and `maxLike` functions. | function | description | |----------|-------------| | `eachLike()` | Ensure that each item in the list matches the provided example | | `maxLike(integer max)` | Ensure that each item in the list matches the provided example and the list is no bigger than the provided max | | `minLike(integer min)` | Ensure that each item in the list matches the provided example and the list is no smaller than the provided min | For example: ```groovy withBody { users minLike(1) { id identifier name string(&apos;Fred&apos;) } } ``` This will ensure that the user list is never empty and that each user has an identifier that is a number and a name that is a string. You can specify the number of example items to generate in the array. The default is 1. ```groovy withBody { users minLike(1, 3) { id identifier name string(&apos;Fred&apos;) } } ``` This will create an example user list with 3 users. The each like matchers have been updated to work with primitive types. ```groovy withBody { permissions eachLike(3, &apos;GRANT&apos;) } ``` will generate the following JSON ```json { &quot;permissions&quot;: [&quot;GRANT&quot;, &quot;GRANT&quot;, &quot;GRANT&quot;] } ``` and matchers ```json { &quot;$.body.permissions&quot;: {&quot;match&quot;: &quot;type&quot;} } ``` and now you can even get more fancy ```groovy withBody { permissions eachLike(3, regexp(~/\w+/)) permissions2 minLike(2, 3, integer()) permissions3 maxLike(4, 3, ~/\d+/) } ``` You can also match arrays at the root level, for instance, ```groovy withBody PactBodyBuilder.eachLike(regexp(~/\w+/)) ``` or if you have arrays of arrays ```groovy withBody PactBodyBuilder.eachLike([ regexp(&apos;[0-9a-f]{8}&apos;, &apos;e8cda07e&apos;), regexp(~/\w+/, &apos;sony&apos;) ]) ``` An `eachArrayLike` method has been added to handle matching of arrays of arrays. ```groovy { answers minLike(1) { questionId string(&quot;books&quot;) answer eachArrayLike { questionId string(&quot;title&quot;) answer string(&quot;BBBB&quot;) } } ``` This will generate an array of arrays for the `answer` attribute. ### Matching any key in a map 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 `keyLike` method, which takes an example key as a parameter. For example: ```groovy withBody { example { one { keyLike &apos;001&apos;, &apos;value&apos; // key like an id mapped to a value } two { keyLike &apos;ABC001&apos;, regexp(&apos;\\w+&apos;) // key like an id mapped to a matcher } three { keyLike &apos;XYZ001&apos;, { // key like an id mapped to a closure id identifier() } } four { keyLike &apos;001XYZ&apos;, eachLike { // key like an id mapped to an array where each item is matched by the following id identifier() // example } } } } ``` For an example, have a look at [WildcardPactSpec](src/test/au/com/dius/pact/consumer/groovy/WildcardPactSpec.groovy). **NOTE:** The `keyLike` 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 `keyLike` condition applied to a map will result in only one being applied when the pact is verified (probably the last). **Further Note: From version 3.5.22 onwards pacts with wildcards applied to map keys will require the Java system property &quot;pact.matching.wildcard&quot; set to value &quot;true&quot; when the pact file is verified.** ### Matching with an OR The V3 spec allows multiple matchers to be combined using either AND or OR for a value. The main use of this would be to either be able to match a value or a null, or to combine different matchers. For example: ```groovy withBody { valueA and(&apos;AB&apos;, includeStr(&apos;A&apos;), includeStr(&apos;B&apos;)) // valueA must include both A and B valueB or(&apos;100&apos;, regex(~/\d+/), nullValue()) // valueB must either match a regular expression or be null valueC or(&apos;12345678&apos;, regex(~/\d{8}/), regex(~/X\d{13}/)) // valueC must match either 8 or X followed by 13 digits } ``` ## Changing the directory pact files are written to By default, pact files are written to `target/pacts` (or `build/pacts` if you use Gradle), 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[&apos;pact.rootDir&apos;] = &quot;$buildDir/custom-pacts-directory&quot; } ``` ## Forcing pact files to be overwritten (3.6.5+) By default, when the pact file is written, it will be merged with any existing pact file. To force the file to be overwritten, set the Java system property `pact.writer.overwrite` to `true`. # 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/provider/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. * Multiple provider states can be defined with data parameters. ## Generating V3 spec pact files To have your consumer tests generate V3 format pacts, you can pass an option into the `runTest` method. For example: ```groovy PactVerificationResult result = service.runTest(specificationVersion: PactSpecVersion.V3) { config -&gt; def client = new RESTClient(config.url) def response = client.get(path: &apos;/&apos;) } ``` ## Consumer test for a message consumer For testing a consumer of messages from a message queue, the `PactMessageBuilder` class provides a DSL for defining your message expectations. It works in much the same way as the `PactBuilder` class for Request-Response interactions, but will generate a V3 format message pact file. The following steps demonstrate how to use it. ### Step 1 - define the message expectations Create a test that uses the `PactMessageBuilder` to define a message expectation, and then call `run`. This will invoke the given closure with a message for each one defined in the pact. ```groovy def eventStream = new PactMessageBuilder().call { serviceConsumer &apos;messageConsumer&apos; hasPactWith &apos;messageProducer&apos; given &apos;order with id 10000004 exists&apos; expectsToReceive &apos;an order confirmation message&apos; withMetaData(type: &apos;OrderConfirmed&apos;) // Can define any key-value pairs here withContent(contentType: &apos;application/json&apos;) { type &apos;OrderConfirmed&apos; audit { userCode &apos;messageService&apos; } origin &apos;message-service&apos; referenceId &apos;10000004-2&apos; timeSent: &apos;2015-07-22T10:14:28+00:00&apos; value { orderId &apos;10000004&apos; value &apos;10.000000&apos; fee &apos;10.00&apos; gst &apos;15.00&apos; } } } ``` ### Step 2 - call your message handler with the generated messages This example tests a message handler that gets messages from a Kafka topic. In this case the Pact message is wrapped as a Kafka `MessageAndMetadata`. ```groovy eventStream.run { Message message -&gt; messageHandler.handleMessage(new MessageAndMetadata(&apos;topic&apos;, 1, new kafka.message.Message(message.contentsAsBytes()), 0, null, valueDecoder)) } ``` ### Step 3 - validate that the message was handled correctly ```groovy def order = orderRepository.getOrder(&apos;10000004&apos;) assert order.status == &apos;confirmed&apos; assert order.value == 10.0 ``` ### Step 4 - Publish the pact file If the test was successful, a pact file would have been produced with the message from step 1. # Having values injected from provider state callbacks (3.6.11+) You can have values from the provider state callbacks be injected into most places (paths, query parameters, headers, bodies, etc.). This works by using the V3 spec generators with provider state callbacks that return values. One example of where this would be useful is API calls that require an ID which would be auto-generated by the database on the provider side, so there is no way to know what the ID would be beforehand. The DSL method `fromProviderState` allows you to set an expression that will be parsed with the values returned from the provider states. For the body, you can use the key value instead of an expression. For example, assume that an API call is made to get the details of a user by ID. A provider state can be defined that specifies that the user must be exist, but the ID will be created when the user is created. So we can then define an expression for the path where the ID will be replaced with the value returned from the provider state callback. ```groovy service { given(&apos;User harry exists&apos;) uponReceiving(&apos;a request for user harry&apos;) withAttributes(method: &apos;get&apos;, path: fromProviderState(&apos;/api/user/${id}&apos;, &apos;/api/user/100&apos;)) withBody { name(fromProviderState(&apos;userName&apos;, &apos;harry&apos;)) // looks up the value using the userName key } } ```

pact-jvm-consumer-groovy ========================= Groovy DSL for Pact JVM ##Dependency The library is available on maven central using: * group-id = `au.com.dius` * artifact-id = `pact-jvm-consumer-groovy_2.11` * version-id = `2.1.0` ##Usage Add the `pact-jvm-consumer-groovy` library to your test class path. This provides a `PactBuilder` class for you to use to define your pacts. For a full example, have a look at the example JUnit `ExampleGroovyConsumerPactTest`. If you are using gradle for your build, add it to your `build.gradle`: dependencies { testCompile 'au.com.dius:pact-jvm-consumer-groovy_2.11:2.1.0' } Then create an instance of the `PactBuilder` in your test. ```groovy @Test void "A service consumer side of a pact goes a little something like this"() { def alice_service = new PactBuilder() // Create a new PactBuilder alice_service { serviceConsumer "Consumer" // Define the service consumer by name hasPactWith "Alice Service" // Define the service provider that it has a pact with port 1234 // The port number for the service. It is optional, leave it out to // to use a random one given('there is some good mallory') // defines a provider state. It is optional. uponReceiving('a retrieve Mallory request') // upon_receiving starts a new interaction withAttributes(method: 'get', path: '/mallory') // define the request, a GET request to '/mallory' willRespondWith( // define the response we want returned status: 200, headers: ['Content-Type': 'text/html'], body: '"That is some good Mallory."' ) } // Execute the run method to have the mock server run. // It takes a closure to execute your requests and returns a Pact VerificationResult. VerificationResult result = alice_service.run() { def client = new RESTClient('http://localhost:1234/') def alice_response = client.get(path: '/mallory') assert alice_response.status == 200 assert alice_response.contentType == 'text/html' def data = alice_response.data.text() assert data == '"That is some good Mallory."' } assert result == PactVerified$.MODULE$ // This means it is all good in weird Scala speak. } ``` After running this test, the following pact file is produced: { "provider" : { "name" : "Alice Service" }, "consumer" : { "name" : "Consumer" }, "interactions" : [ { "provider_state" : "there is some good mallory", "description" : "a retrieve Mallory request", "request" : { "method" : "get", "path" : "/mallory", "requestMatchers" : { } }, "response" : { "status" : 200, "headers" : { "Content-Type" : "text/html" }, "body" : "That is some good Mallory.", "responseMatchers" : { } } } ] } ### DSL Methods #### serviceConsumer(String consumer) This names the service consumer for the pact. #### hasPactWith(String provider) This names the service provider for the pact. #### port(int port) Sets the port that the mock server will run on. If not supplied, a random port will be used. #### given(String providerState) Defines a state that the provider needs to be in for the request to succeed. For more info, see https://github.com/realestate-com-au/pact/wiki/Provider-states #### uponReceiving(String requestDescription) Starts the definition of a of a pact interaction. #### withAttributes(Map requestData) Defines the request for the interaction. The request data map can contain the following: | key | Description | Default Value | |----------------------------|-------------------------------------------|-----------------------------| | method | The HTTP method to use | get | | path | The Path for the request | / | | query | Query parameters as a Map<String, List> | | | headers | Map of key-value pairs for the request headers | | | body | The body of the request. If it is not a string, it will be converted to JSON. Also accepts a PactBodyBuilder. | | #### withBody(Closure closure) Constructs the body of the request or response by invoking the supplied closure in the context of a PactBodyBuilder. #### willRespondWith(Map responseData) Defines the response for the interaction. The response data map can contain the following: | key | Description | Default Value | |----------------------------|-------------------------------------------|-----------------------------| | status | The HTTP status code to return | 200 | | headers | Map of key-value pairs for the response headers | | | body | The body of the response. If it is not a string, it will be converted to JSON. Also accepts a PactBodyBuilder. | | #### VerificationResult run(Closure closure) The `run` method starts the mock server, and then executes the provided closure. It then returns the pact verification result for the pact run. If you require access to the mock server configuration for the URL, it is passed into the closure, e.g., ```groovy VerificationResult result = alice_service.run() { config -> def client = new RESTClient(config.url()) def alice_response = client.get(path: '/mallory') } ``` ### Body DSL For building JSON bodies there is a `PactBodyBuilder` that provides as DSL that includes matching with regular expressions and by types. For a more complete example look at `PactBodyBuilderTest`. For an example: ```groovy service { uponReceiving('a request') withAttributes(method: 'get', path: '/') withBody { name(~/\w+/, 'harry') surname regexp(~/\w+/, 'larry') position regexp(~/staff|contractor/, 'staff') happy(true) } } ``` This will return the following body: ```json { "name": "harry", "surname": "larry", "position": "staff", "happy": true } ``` and add the following matchers: ```json "$.body.name": ["regex": "\\w+"], "$.body.surname": ["regex": "\\w+"], "$.body.position": ["regex": "staff|contractor"] ``` #### DSL Methods The DSL supports the following matching methods: * regexp(Pattern re, String value = null), regexp(String regexp, String value = null) Defines a regular expression matcher. If the value is not provided, a random one will be generated. * hexValue(String value = null) Defines a matcher that accepts hexidecimal values. If the value is not provided, a random hexidcimal value will be generated. * identifier(def value = null) Defines a matcher that accepts integer values. If the value is not provided, a random value will be generated. * ipAddress(String value = null) Defines a matcher that accepts IP addresses. If the value is not provided, a 127.0.0.1 will be used. * numeric(Number value = null) Defines a matcher that accepts any numerical values. If the value is not provided, a random integer will be used. * timestamp(def value = null) Defines a matcher that accepts ISO and SMTP timestamps. If the value is not provided, the current date and time is used. * guid(String value = null) Defines a matcher that accepts UUIDs. A random one will be generated if no value is provided.

This is the main aggregator for all gwt submodules. All gwt-specific code resides here. Submodules should avoid inheriting from each other unless necessary. This goes for maven structure and gwt.xml structure. The super module is where our jre emulation layer and super-source live; all modules should inherit super, and a minimum of other modules. Some modules, like injection, are fulfilling an api in the core module, and should be accessed only through core service interfaces. Other modules, like reflection, are capable of being standalone inherits, but can benefit from core utilities like injection, so, two (or more) .gwt.xml modules may be provided. As XApi nears 1.0, all submodules will be routinely stitched together into an uber-jar, in order to have a single jar with a single gwt module that can provide all of the services at once. Internal projects will never use the uber jar, to help maintain modularity, but external projects that want to use more than one service will certainly prefer inheriting one artifact, instead of twelve. When distributed in uber-jar format, it will likely be necessary for either the uber jar, or just xapi-gwt-api.jar to appear before gwt-dev on your compile-time classpath. If using gwt-maven-plugin, the gwtFirstOnClasspath option may become problematic. If so, we will provide a forked gwt-plugin to make sure our compiler enhancements are included in the build process. There is also work going on to make a super-source-everything plugin, which will use maven to find source files, and generate synthetic .gwt.xml for you, as part of an effort to create a wholly unified programming environment. In addition to java-to-javascript, we intend to compile java-to-java and possibly other languages, like go; imagine implementing gwt deferred binding to eliminate cross-platform differences between server environments, or operating systems, or versions of a platform, or anywhere else a core api needs to bind to multiple implementations, depending on the runtime environment.

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 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(&quot;Some Consumer&quot;) .hasPactWith(&quot;Some Provider&quot;) .uponReceiving(&quot;a request to say Hello&quot;) .path(&quot;/hello&quot;) .method(&quot;POST&quot;) .body(&quot;{\&quot;name\&quot;: \&quot;harry\&quot;}&quot;) .willRespondWith() .status(200) .body(&quot;{\&quot;hello\&quot;: \&quot;harry\&quot;}&quot;) .toFragment(); MockProviderConfig config = MockProviderConfig.createDefault(); VerificationResult result = pactFragment.runConsumer(config, new TestRun() { @Override public void run(MockProviderConfig config) { Map expectedResponse = new HashMap(); expectedResponse.put(&quot;hello&quot;, &quot;harry&quot;); try { assertEquals(new ProviderClient(config.url()).hello(&quot;{\&quot;name\&quot;: \&quot;harry\&quot;}&quot;), 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(&quot;Some Consumer&quot;) .hasPactWith(&quot;Some Provider&quot;) .given(&quot;a certain state on the provider&quot;) .uponReceiving(&quot;a request for something&quot;) .path(&quot;/hello&quot;) .method(&quot;POST&quot;) .body(&quot;{\&quot;name\&quot;: \&quot;harry\&quot;}&quot;) .willRespondWith() .status(200) .body(&quot;{\&quot;hello\&quot;: \&quot;harry\&quot;}&quot;) .uponReceiving(&quot;another request for something&quot;) .path(&quot;/hello&quot;) .method(&quot;POST&quot;) .body(&quot;{\&quot;name\&quot;: \&quot;harry\&quot;}&quot;) .willRespondWith() .status(200) .body(&quot;{\&quot;hello\&quot;: \&quot;harry\&quot;}&quot;) . . . .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(&quot;name&quot;) .booleanType(&quot;happy&quot;) .hexValue(&quot;hexCode&quot;) .id() .ipAddress(&quot;localAddress&quot;) .numberValue(&quot;age&quot;, 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(&quot;users&quot;) .id() .stringType(&quot;name&quot;) .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(&quot;Some Consumer&quot;) .hasPactWith(&quot;Some Provider&quot;) .uponReceiving(&quot;a request for a basic JSON value&quot;) .path(&quot;/hello&quot;) .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(&quot;clearedDate&quot;, &quot;mm/dd/yyyy&quot;, date) .stringType(&quot;status&quot;, &quot;STATUS&quot;) .decimalType(&quot;amount&quot;, 100.0) .closeObject() ``` This will then match a body like: ```json [ { &quot;clearedDate&quot; : &quot;07/22/2015&quot;, &quot;status&quot; : &quot;C&quot;, &quot;amount&quot; : 15.0 }, { &quot;clearedDate&quot; : &quot;07/22/2015&quot;, &quot;status&quot; : &quot;C&quot;, &quot;amount&quot; : 15.0 }, { &quot;clearedDate&quot; : &quot;07/22/2015&quot;, &quot;status&quot; : &quot;C&quot;, &quot;amount&quot; : 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(&quot;type&quot;,&quot;FeatureCollection&quot;) .eachLike(&quot;features&quot;) .stringType(&quot;type&quot;,&quot;Feature&quot;) .object(&quot;geometry&quot;) .stringType(&quot;type&quot;,&quot;Point&quot;) .eachArrayLike(&quot;coordinates&quot;) // coordinates is an array of arrays .decimalType(-7.55717) .decimalType(49.766896) .closeArray() .closeArray() .closeObject() .object(&quot;properties&quot;) .stringType(&quot;prop0&quot;,&quot;value0&quot;) .closeObject() .closeObject() .closeArray() ``` This generated the following JSON: ```json { &quot;features&quot;: [ { &quot;geometry&quot;: { &quot;coordinates&quot;: [[-7.55717, 49.766896]], &quot;type&quot;: &quot;Point&quot; }, &quot;type&quot;: &quot;Feature&quot;, &quot;properties&quot;: { &quot;prop0&quot;: &quot;value0&quot; } } ], &quot;type&quot;: &quot;FeatureCollection&quot; } ``` 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(&quot;one&quot;) .eachKeyLike(&quot;001&quot;, PactDslJsonRootValue.id(12345L)) // key like an id mapped to a matcher .closeObject() .object(&quot;two&quot;) .eachKeyLike(&quot;001-A&quot;) // key like an id where the value is matched by the following example .stringType(&quot;description&quot;, &quot;Some Description&quot;) .closeObject() .closeObject() .object(&quot;three&quot;) .eachKeyMappedToAnArrayLike(&quot;001&quot;) // key like an id mapped to an array where each item is matched by the following example .id(&quot;someId&quot;, 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(&quot;test state&quot;) .uponReceiving(&quot;a test interaction&quot;) .matchPath(&quot;/transaction/[0-9]+&quot;) // or .matchPath(&quot;/transaction/[0-9]+&quot;, &quot;/transaction/1234567890&quot;) .method(&quot;POST&quot;) .body(&quot;{\&quot;name\&quot;: \&quot;harry\&quot;}&quot;) .willRespondWith() .status(200) .body(&quot;{\&quot;hello\&quot;: \&quot;harry\&quot;}&quot;) ``` ### 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(&quot;test state&quot;) .uponReceiving(&quot;a test interaction&quot;) .path(&quot;/hello&quot;) .method(&quot;POST&quot;) .matchHeader(&quot;testreqheader&quot;, &quot;test.*value&quot;) .body(&quot;{\&quot;name\&quot;: \&quot;harry\&quot;}&quot;) .willRespondWith() .status(200) .body(&quot;{\&quot;hello\&quot;: \&quot;harry\&quot;}&quot;) .matchHeader(&quot;Location&quot;, &quot;.*/hello/[0-9]+&quot;, &quot;/hello/1234&quot;) ``` ### 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(&quot;test state&quot;) .uponReceiving(&quot;a test interaction&quot;) .path(&quot;/hello&quot;) .method(&quot;POST&quot;) .matchQuery(&quot;a&quot;, &quot;\\d+&quot;, &quot;100&quot;) .matchQuery(&quot;b&quot;, &quot;[A-Z]&quot;, &quot;X&quot;) .body(&quot;{\&quot;name\&quot;: \&quot;harry\&quot;}&quot;) .willRespondWith() .status(200) .body(&quot;{\&quot;hello\&quot;: \&quot;harry\&quot;}&quot;) ```

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.RequestResponsePact; import org.apache.http.entity.ContentType; import org.jetbrains.annotations.NotNull; import org.junit.Test; import java.io.IOException; import java.util.HashMap; import java.util.Map; import static au.com.dius.pact.consumer.ConsumerPactRunnerKt.runConsumerTest; import static org.junit.Assert.assertEquals; public class PactTest { @Test public void testPact() { RequestResponsePact pact = ConsumerPactBuilder .consumer(&quot;Some Consumer&quot;) .hasPactWith(&quot;Some Provider&quot;) .uponReceiving(&quot;a request to say Hello&quot;) .path(&quot;/hello&quot;) .method(&quot;POST&quot;) .body(&quot;{\&quot;name\&quot;: \&quot;harry\&quot;}&quot;) .willRespondWith() .status(200) .body(&quot;{\&quot;hello\&quot;: \&quot;harry\&quot;}&quot;) .toPact(); MockProviderConfig config = MockProviderConfig.createDefault(); PactVerificationResult result = runConsumerTest(pact, config, new PactTestRun() { @Override public void run(@NotNull MockServer mockServer) throws IOException { Map expectedResponse = new HashMap(); expectedResponse.put(&quot;hello&quot;, &quot;harry&quot;); assertEquals(expectedResponse, new ConsumerClient(mockServer.getUrl()).post(&quot;/hello&quot;, &quot;{\&quot;name\&quot;: \&quot;harry\&quot;}&quot;, ContentType.APPLICATION_JSON)); } }); if (result instanceof PactVerificationResult.Error) { throw new RuntimeException(((PactVerificationResult.Error)result).getError()); } assertEquals(PactVerificationResult.Ok.INSTANCE, result); } } ``` The DSL has the following pattern: ```java .consumer(&quot;Some Consumer&quot;) .hasPactWith(&quot;Some Provider&quot;) .given(&quot;a certain state on the provider&quot;) .uponReceiving(&quot;a request for something&quot;) .path(&quot;/hello&quot;) .method(&quot;POST&quot;) .body(&quot;{\&quot;name\&quot;: \&quot;harry\&quot;}&quot;) .willRespondWith() .status(200) .body(&quot;{\&quot;hello\&quot;: \&quot;harry\&quot;}&quot;) .uponReceiving(&quot;another request for something&quot;) .path(&quot;/hello&quot;) .method(&quot;POST&quot;) .body(&quot;{\&quot;name\&quot;: \&quot;harry\&quot;}&quot;) .willRespondWith() .status(200) .body(&quot;{\&quot;hello\&quot;: \&quot;harry\&quot;}&quot;) . . . .toPact() ``` 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(&quot;name&quot;) .booleanType(&quot;happy&quot;) .hexValue(&quot;hexCode&quot;) .id() .ipAddress(&quot;localAddress&quot;) .numberValue(&quot;age&quot;, 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 | | includesStr | Will match strings containing the provided string | | equalsTo | Will match using equals | | matchUrl | Defines a matcher for URLs, given the base URL path and a sequence of path fragments. The path fragments could be strings or regular expression matchers | _\* 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(&quot;users&quot;) .id() .stringType(&quot;name&quot;) .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(&quot;Some Consumer&quot;) .hasPactWith(&quot;Some Provider&quot;) .uponReceiving(&quot;a request for a basic JSON value&quot;) .path(&quot;/hello&quot;) .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(&quot;clearedDate&quot;, &quot;mm/dd/yyyy&quot;, date) .stringType(&quot;status&quot;, &quot;STATUS&quot;) .decimalType(&quot;amount&quot;, 100.0) .closeObject() ``` This will then match a body like: ```json [ { &quot;clearedDate&quot; : &quot;07/22/2015&quot;, &quot;status&quot; : &quot;C&quot;, &quot;amount&quot; : 15.0 }, { &quot;clearedDate&quot; : &quot;07/22/2015&quot;, &quot;status&quot; : &quot;C&quot;, &quot;amount&quot; : 15.0 }, { &quot;clearedDate&quot; : &quot;07/22/2015&quot;, &quot;status&quot; : &quot;C&quot;, &quot;amount&quot; : 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(&quot;type&quot;,&quot;FeatureCollection&quot;) .eachLike(&quot;features&quot;) .stringType(&quot;type&quot;,&quot;Feature&quot;) .object(&quot;geometry&quot;) .stringType(&quot;type&quot;,&quot;Point&quot;) .eachArrayLike(&quot;coordinates&quot;) // coordinates is an array of arrays .decimalType(-7.55717) .decimalType(49.766896) .closeArray() .closeArray() .closeObject() .object(&quot;properties&quot;) .stringType(&quot;prop0&quot;,&quot;value0&quot;) .closeObject() .closeObject() .closeArray() ``` This generated the following JSON: ```json { &quot;features&quot;: [ { &quot;geometry&quot;: { &quot;coordinates&quot;: [[-7.55717, 49.766896]], &quot;type&quot;: &quot;Point&quot; }, &quot;type&quot;: &quot;Feature&quot;, &quot;properties&quot;: { &quot;prop0&quot;: &quot;value0&quot; } } ], &quot;type&quot;: &quot;FeatureCollection&quot; } ``` 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/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(&quot;one&quot;) .eachKeyLike(&quot;001&quot;, PactDslJsonRootValue.id(12345L)) // key like an id mapped to a matcher .closeObject() .object(&quot;two&quot;) .eachKeyLike(&quot;001-A&quot;) // key like an id where the value is matched by the following example .stringType(&quot;description&quot;, &quot;Some Description&quot;) .closeObject() .closeObject() .object(&quot;three&quot;) .eachKeyMappedToAnArrayLike(&quot;001&quot;) // key like an id mapped to an array where each item is matched by the following example .id(&quot;someId&quot;, 23456L) .closeObject() .closeArray() .closeObject(); ``` For an example, have a look at [WildcardKeysTest](../pact-jvm-consumer-junit/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). **Further Note: From version 3.5.22 onwards pacts with wildcards applied to map keys will require the Java system property &quot;pact.matching.wildcard&quot; set to value &quot;true&quot; when the pact file is verified.** ### 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(&quot;test state&quot;) .uponReceiving(&quot;a test interaction&quot;) .matchPath(&quot;/transaction/[0-9]+&quot;) // or .matchPath(&quot;/transaction/[0-9]+&quot;, &quot;/transaction/1234567890&quot;) .method(&quot;POST&quot;) .body(&quot;{\&quot;name\&quot;: \&quot;harry\&quot;}&quot;) .willRespondWith() .status(200) .body(&quot;{\&quot;hello\&quot;: \&quot;harry\&quot;}&quot;) ``` ### 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(&quot;test state&quot;) .uponReceiving(&quot;a test interaction&quot;) .path(&quot;/hello&quot;) .method(&quot;POST&quot;) .matchHeader(&quot;testreqheader&quot;, &quot;test.*value&quot;) .body(&quot;{\&quot;name\&quot;: \&quot;harry\&quot;}&quot;) .willRespondWith() .status(200) .body(&quot;{\&quot;hello\&quot;: \&quot;harry\&quot;}&quot;) .matchHeader(&quot;Location&quot;, &quot;.*/hello/[0-9]+&quot;, &quot;/hello/1234&quot;) ``` ### 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(&quot;test state&quot;) .uponReceiving(&quot;a test interaction&quot;) .path(&quot;/hello&quot;) .method(&quot;POST&quot;) .matchQuery(&quot;a&quot;, &quot;\\d+&quot;, &quot;100&quot;) .matchQuery(&quot;b&quot;, &quot;[A-Z]&quot;, &quot;X&quot;) .body(&quot;{\&quot;name\&quot;: \&quot;harry\&quot;}&quot;) .willRespondWith() .status(200) .body(&quot;{\&quot;hello\&quot;: \&quot;harry\&quot;}&quot;) ``` # Forcing pact files to be overwritten (3.6.5+) By default, when the pact file is written, it will be merged with any existing pact file. To force the file to be overwritten, set the Java system property `pact.writer.overwrite` to `true`. # Having values injected from provider state callbacks (3.6.11+) You can have values from the provider state callbacks be injected into most places (paths, query parameters, headers, bodies, etc.). This works by using the V3 spec generators with provider state callbacks that return values. One example of where this would be useful is API calls that require an ID which would be auto-generated by the database on the provider side, so there is no way to know what the ID would be beforehand. The following DSL methods allow you to set an expression that will be parsed with the values returned from the provider states: For JSON bodies, use `valueFromProviderState`.&lt;br/&gt; For headers, use `headerFromProviderState`.&lt;br/&gt; For query parameters, use `queryParameterFromProviderState`.&lt;br/&gt; For paths, use `pathFromProviderState`. For example, assume that an API call is made to get the details of a user by ID. A provider state can be defined that specifies that the user must be exist, but the ID will be created when the user is created. So we can then define an expression for the path where the ID will be replaced with the value returned from the provider state callback. ```java .pathFromProviderState(&quot;/api/users/${id}&quot;, &quot;/api/users/100&quot;) ``` You can also just use the key instead of an expression: ```java .valueFromProviderState(&apos;userId&apos;, &apos;userId&apos;, 100) // will look value using userId as the key ```