Contracts vs Features in Spring Cloud Contract

I understand that contract tests are used to test contracts between applications and not to be used as checkers for business features. Write one contract for the positive scenario, one for the negative.

But imagine the following examples:

// contract (#1)

org.springframework.cloud.contract.spec.Contract.make {
  request {
    method 'GET'
    url 'client/1'
  }
  response {
    status 200
    body([
        id: 1
        name: "Barbara"
        address: "Park Avenue 1"
    ])
  }
}


// contract (#2)

org.springframework.cloud.contract.spec.Contract.make {
  request {
    method 'GET'
    url 'client/9999'
  }
  response {
    status 404
    body([])
  }
}


// contract (#3)

org.springframework.cloud.contract.spec.Contract.make {
  request {
    method 'GET'
    url 'client/!^&(^%@'
  }
  response {
    status 400
    body([])
  }
}

My positive case it's when the client is found (#1). Can I pass variables in the url, is this possible in SCC? Can I use regular expressions here to validate input?

I kind of felt the need for two negative cases: -- the user does not exist (#2), -- the request is invalid (#3)

Is this reasonable or am I missing the point with regard to Consumer-Driven Contracts? Would you write any on these contracts?

I'm also having problems reasoning about the producer side. If the above was somehow reasonable, then in the producer side I will have (auto generated) tests for the contracts, but how can I make a distinction between an existing and unexisting client? I know that it doesn't make sense that the contract cares about real data... but how to test the contract (#2), when a user does not exist?

Solution

These are very good questions!! I'll try to answer them one by one.

1 yes you can pass variables and regular expressions. If you have a regular expression and a contact with a concrete value then you have to use priorities to define the order.

2 i think that #3 i wouldn't put it in a contract but treat it manually with a WireMock or some other http server stub. I'd simulate different exceptions and ensure that I can handle them. In talking about technical exceptions. If the producer app can send an error due to business reasons then i think I'd write a contact for it. And i think that in this case #2 is such an exception cause the URL exists but there is no client.

As for the producer side... Pick a name for the client. For example "nonexistent" and for that one return 404. Set the priority to 1. And create another one with a regex and set a priority to 5 or sth.