It's a simple example that I can't seem to find - in our current implementation we have things like

.given('a user exists and has transactions')

in our consumer tests, and in our provider tests, a method that takes this state and sets up the data/mocking needed to be able to emulate that state

I think you have just got a bit mixed up here buddy, the above is for CDCT and we have plenty of examples. Would love to know if there is something in the docs which has led you to this path, or if there is something we can had to clear this up.

I got to this, as we are currently using CDCT, and looking at if the move to BDCT brings benefits - I would recommend a "Migrating from one to the other" document, highlighting what it will do and what it won't do 👍

Thanks man, for the really good insight • I'm not sure we would ever advocate migrating from CDCT to BDCT, but • would definitely suggest using BDCT for coverage of services CDCT is not suited for, • would definitely suggest moving to CDCT from BDCT, where BDCT was used as a tool to get initial organisation buy-in / support for contract testing in general, and you can move to CDCT for stronger guarantees So definitely see a hybrid model working or a BDCT -> CDCT (So you've dipped your toe in the contract testing water, and now you want to get wet!) I am going to assume you've seen these two sections • https://docs.pactflow.io/docs/bi-directional-contract-testing#use-cases • https://docs.pactflow.io/docs/bi-directional-contract-testing#comparison-to-pact Lastly, whilst I've got your attention man, what type of format do you prefer, (docs, examples. videos. repos, blog?) thanks again

• I'm not sure we would ever advocate migrating from CDCT to BDCT, but

Worth thinking about how the advertising/promo for this is in the pre-launch material - it went out to all the current users as "here's the next big thing.." 🙂

It is massive for current users, because if they are using CDCT and getting benefits, they will want to use it everywhere (and that causes everyone pain - maintainers, community supporters, users). We have a guide of what Pact isn't good for, and BDCT helps address many of these pains. These docs will be linked in with all the advertising material, and we were quite clear that BDCT does replace nor reduce our ❤️ for CDCT, but rather compliments ours users needs and workflows. Really good food for thought

We like the product, but the docs are hard work to read and find out how to build an end-to-end solution - there are a lot of examples that are somewhat light on real-world examples (like our aforementioned `200`/`401` example). Chunks of it feels like docs that are written by devs who obviously know a lot, but sometimes forget that people reading it don't 😉 This is understandable, I've done it plenty of times 😄

Chunks of it feels like docs that are written by devs who obviously know a lot, but sometimes forget that people reading it don’t 😉

We feel you! It’s one thing to know what good docs look like, it’s whole other thing to do it!

Yeah, the devs have been busy devvin' They now have me to help free them up to help look after the community and help find out what you need, so the docs are well in my sights and I've had a rollercoaster going through them, so definitely keen to help reduce the cognitive load. We have 401 failure cases in our CDCT examples, and it should be easy enough for me to add them into the BDCT examples. Have you got any other possible real world examples that would help? I have long looked at and lusted after the gothinksters real world project https://github.com/gothinkster/realworld

authentication failures was our first hurdle - we also have some endpoints where the response is different depending on the RBAC role of the user, but I think that would be covered by the OpenAPI comparison to the consumer mocks.