Hello! I was wondering if there is guidance on best practices around things like contract test code organization? • Do you recommend putting your consumer contract unit tests in their own folder, or alongside other unit tests in your project? • Should they have their own spec_helper files? • Similarly on the provider side: best practices for organizing provider states. For example, should all of the states for a single consumer go in one file? Should states be able to be shared across consumers? We are just getting off the ground with pact and would like to leverage any learnings from those of you with experience. Thank you in advance!

I'm not a ruby person, but:

Do you recommend putting your consumer contract unit tests in their own folder, or alongside other unit tests in your project?

I put them wherever I would normally put tests for the code that the consumer contract is calling

Should they have their own spec_helper files?

I'm not qualified to answer this. I think it would depend on if they uniquely need their own spec_helper.

best practices for organizing provider states. For example, should all of the states for a single consumer go in one file?

My guideline for this is - how many states are there? I think it's best if files are kept under 250 lines in general, so it would depend on that. In some ecosystems it might be hard to separate out the states.

Should states be able to be shared across consumers?

Ideally states are about the provider and not about the consumer, so it should be fine to share them. However, there's usually a need for some alignment between provider and consumer teams, since the consumer team are the people writing the state into the contract. If I were adding a consumer to a provider that already had some states, I would review the states to see if there were some that I could re-use.

Awesome, thank you @Timothy Jones! This is great! If anyone else has their own thoughts, I welcome any more input.

My pact tests just run as part of the normal unit test suite with the normal settings.

Thank you, Beth! We are configuring WebMock to do so as we speak.