set the channel description: Alternative contract file format produced by Case

has renamed the channel from "case-contracts" to "contract-case"

Hey all! I’m Dan, looking to take a stab at porting a Kotlin DSL for Contract Case. Sorry in advance for any spam as I ask all the silly questions

First up is about defaults/required properties for configuration in the DSL’s. There is some mention of default values in the docs. I’m unsure if I should be: • Implementing those defaults in the DSL layer • Using the type system to help me enforce required properties, or leaving that to core validation • Duplicating the documentation - I would like consumers (of the library) to be able to get a good understanding of required values and defaults directly from the Kdoc in their IDE

Another separate thread for this one since it’s a bit specific: • Skipping passing nulls to the boundary layer for unset values The Java DSL BoundaryConfigMapper conditionally maps values to the boundary if they are not null.

if (config.brokerBaseUrl != null) {
      builder.brokerBaseUrl(config.brokerBaseUrl);
    }

Is there a reason we don’t map everything anyway, even if the property is null? Looking at the Jsii types it seems like these should be nullable for the most part

Also, @Dan Nichols - I mentioned this elsewhere, but it should go here too - frustratingly the JSii boundary won't work at all until this is fixed. And I think we (I?) are going to have to fix it: https://github.com/aws/jsii/issues/4133

Can I confirm something from the docs? It’s about the different ways triggers can be defined. Gonna paraphrase the docs to see if my understanding is correct. The 3 ways to define a trigger are: 1. In the

runExample

arguments (for a successful response) 2. In the

runRejectingExample

arguments (for an unsuccessful response) 3. A group of named triggers in the ContractCaseConfig object (for contract verification) The docs has the usage of (1) as:

await contract.runExample({
    states: [...], // These `...` are not spreads, just for brevity
    definition: willSendHttpRequest(...),
  },
  {
    // Presumably the ContractCaseConfig object as an override for the parent config
    trigger: (config: HttpRequestConfig) => {},
    testResponse: (user) => {}
})

But looking in some examples in the codebase, the triggers are defined as:

contract.runRejectingExample({
    states: [...],
    definition: willSendHttpRequest(...),
    trigger: (config: HttpRequestConfig) => { ... },
    testResponse: (user) => { ... },
});

Are both of these patterns going to be supported? Can I converge on just one of these in the DSL? Looks like the former example is more aligned to the boundary schema, but the latter feels more natural. From the DSL ContractDefiner setup instructions there is a TODO. Is this just going to say that a trigger needs to be paired with a response (whether success or rejecting), and you can’t have one without the other?

TODO: Describe how to map trigger / testResponse - this is the only place where you may throw a

CaseConfigurationError

@Dan Nichols here’s an example use of the Java DSL: Some points: • This is a modification of this pactflow example • The Java ContractCase DSL is SUPER wordy and unpleasant in places. Once I’ve fixed the JSii issue, I plan to do a parse to make it nicer to use / less wordy Define contract:

contract = new ContractDefiner(
        ContractCaseConfig.ContractCaseConfigBuilder.aContractCaseConfig()
            .providerName("Java Example HTTP Server")
            .consumerName("Java Example HTTP Client")
            .publish(PublishType.NEVER)
            .build());

Run example:

@Test
  public void getProduct() {
    contract.runExample(
        new ExampleDefinition<WillSendHttpRequest>(new ArrayList<>(), new WillSendHttpRequest(
            HttpExample.builder()
                .request(
                    new HttpRequest(
                        HttpRequestExample.builder()
                            .path("/product/10")
                            .method("GET")
                            .build()
                    )
                ).response(
                    new HttpResponse(
                        HttpResponseExample
                            .builder()
                            .status(200)
                            .body(
                                Map.of("name", new AnyString("product name"), "type",
                                    new AnyString("product series"), "id",
                                    new AnyString("5cc989d0-d800-434c-b4bb-b1268499e850")
                                )
                            ).build()
                    )
                ).build())),
        IndividualSuccessTestConfig.IndividualSuccessTestConfigBuilder.<Product>builder()
            .withProviderName("Java Example HTTP Server")
            .withConsumerName("Java Example HTTP Client")
            .withLogLevel(LogLevel.DEEP_MAINTAINER_DEBUG)
            .withTrigger(
                config -> {
                  try {
                    return new ProductClient().setUrl(
                            config.get("baseUrl").toString().replace("localhost", "127.0.0.1"))
                        .getProduct("10");
                  } catch (IOException e) {
                    throw new RuntimeException(e);
                  }
                })
            .withTestResponse(
                product -> {
                  assertThat(product.getId(), is("5cc989d0-d800-434c-b4bb-b1268499e850"));
                }).build()
    );

Published some new versions that fix JSii load errors:

def caseCoreVersion = "0.13.0"

dependencies {
    api "io.contract-testing.contractcase:case_example_mock_types:${caseCoreVersion}"
    api "io.contract-testing.contractcase:test-equivalence-matchers:${caseCoreVersion}"
    implementation 'io.contract-testing.contractcase:case_boundary:0.6.3'

Breaking changes:

import io.contract_testing.contractcase.case_example_mock_types.AnyMockDescriptor;

becomes:

import io.contract_testing.contractcase.case_example_mock_types.base.AnyMockDescriptor;

@Dan Nichols What do you need to get Kotlin Native working? C?

Also: Should the boundary expose the ANSI codes?

One of the next tasks is to automate the generation of the matcher documentation