clarify docs to emphasize that pacto is not concerned about server state

[gpolyn]

when i began experimenting with pacto, I thought that I could test message body depending on server state, but my experimentation in pacto/tree/master/samples leads me to conclude that I cannot.

maybe I am incorrect, in which case, I am happy to stand corrected.

if i am correct that pacto is not appropriate for testing varying server state, i suggest it be emphasized in the documentation somewhere.

[maxlinc]

I'm not exactly sure what you mean. Could you explain a bit more?

Keep in mind that you can do [two kinds of testing with Pacto]:

• Contract testing: Makes sure the service is following a Contract. We have our own legacy contract but it will be deprecated in favor of using http://swagger.io/ for contracts.
• Collaboration testing: Tests a specific interaction between the consumer/provider.

The contract testing is fairly automatic but there isn't really a way for it to be stateful.
It should be possible w/ collaboration testing but you'll need to do it as rspec expectations rather than in the contract.

If you can give a simple example of what you'd like to do I may be able to help more.

[gpolyn]

Thanks for your response.

I want to test as many relevant portions of http json request/response as seem important in different api server states. My automated http json api test workflow has been: 1) set up state on http provider service, 2) send http request to provider service, 3) check http response from provider service for failed expectations (, optionally 4) check downstream services from expected side effects from the request/response under examination.) So, with pacto, I was looking to use contracts for my 2) and 3).

My issue is just that it took me a little while to realize that tests with pacto's contracts only cover schema.properties..type or schema.properties..required, not the values of message properties as they change with state.

Relevant to note, here, in your public docs you mention future support is likely for apiblueprint (thoughtworks.github.io/pacto/patterns/documentation_driven), as opposed to swagger, from your reply here.