วีดีโอ

Thanks for the kind words, best of luck with contract testing!

No, PactFlow requires a consumer test to compare against also.

Oh no, the whole point of the AMA was to clarify that - what's not clear?

@@PactFlow it's ok found more info somewhere else.

Bring your own. In this case it means you need to use another tool to perform testing of the API and PactFlow will ensure compatibility with the consumer

There are two primary benefits 1. Is to allow you to write tests for the APIs that don't even exists (e.g. TDD for services) 2. You can use the contracts as stubs too: docs.pact.io/getting_started/stubs

That approach is more provider-driven. Consumer-driven testing doesn't mean the consumer dictates the structure, but it allows the consumers to start documenting their assumptions about the provider before it even exists. The provider always has the right to decline bad assumptions, and Pact has ways to handle this - that is, a Provider won't be held hostage to a set of bad consumers. If it helps, it's a theoretical problem I've never seen in practice in the 10+ years of Pact. You may also like to see our bi-directional testing capability, which supports a design-first or provider-driven workflow (leveraging OpenAPI as part of a "provider contract": docs.pactflow.io/docs/bi-directional-contract-testing)

@@PactFlow got it. so there are different approaches. I'll examine them. thanks for care.

@@basibosturk You're welcome. The best thing to do is give it a go and see what you think. Good luck!

No, that's not what contract testing is about. See also docs.pact.io/consumer/contract_tests_not_functional_tests

Contract testing is more than just ensuring breaking changes. The tests themselves are like any other good test - they apply stress to the design and structure of your code. If Pact tests are hard to write, that is a sign that your code is not very testable and modular and should be improved. There are ways to generate tests though, but you should only consider this once you know what you're doing. You may also like our bi-directional contract testing feature which simplifies this workflow / allows you to re-use mocks and existing testing tools: docs.pactflow.io/docs/bi-directional-contract-testing

Yes, there are two Pact ways to handle this - the use of Provider States and the use of generators. This is one of the neat ways Pact works around the "data fixture" issue. See docs.pact.io/getting_started/terminology#provider-state, docs.pact.io/provider/using_provider_states_effectively and example of dynamic values from the provider here: pactflow.io/blog/injecting-values-from-provider-states/

Yes, publishing a contract is independent of how the contract is generated.

@@fattymellows I mean my consumer logic is written in react . Can I write consumer bi directional test case in java language to generate pact file ?

I think this point is similar to the one made below about "garbage in - garbage out". Sure, there are ways to improve this situation and at a small scale it might be workable, but the reality is that data setup is a costly exercise especially as the size of the ecosystem you're testing grows. You need to know the implementation details of the systems far beyond the direct SUT which at some point becomes unmanageable.

It's on our longer term roadmap, but we don't currently support it in this flow. We do support messaging in the standard consumer-driven flow with Pact however

I'm sorry, is there a point you're trying to make? The video is to help people understand what contract testing is and how it works.

No, you can only publish consumer contracts this way.

As discussed in your SO post, matchers aren't using in BDCT (docs.pactflow.io/docs/bi-directional-contract-testing) so not generating them in this way is not a problem. Only the example request/response cycles are needed for BDCT as a consumer contract.

Yes, I believe the Broker will de-duplicate them based on uniqueness

🤣

In general, I would recommend reading this guide: docs.pact.io/pact_nirvana Branches get set on publishing a contract (using the Pact CLI tools) or verifying pacts (on the verification configuration settings of your provider). They should be sourced from the git repository during the build.

Think of provider states as a precondition for the consumer test to pass (e.g. "user is authenticated" or "user has a positive credit balance"). The states shouldn't have implementation details in them, it is up to the provider to determine how to implement a provider state handler. The provider could seed a database (if it's a 1:1 mapping) or stub a 3rd party API if it's further downstream.

Yes, of course! If you have an issue, please raise it on the linked github repo so we can look into it.

Argh, very sorry about that!

All this in the event of changing the contract itself, for example, at the end you remove the "name" var, the code fails and bla bla... But what if you wanted the contract to change so that it didn't include the name var anymore?

Yes, I think you are missing something. The provider can deploy to production because no consumer is in production yet. Once the provider and consumer are both in production (or any shared environment) Pact won't let you push a breaking change to either of them.

@@FacuConejero-wh8wt That would be a breaking change if the consumer relied on that property. But your general point - Pact is designed to prevent you from having to simultaneously release changes. In fact, you would have to work around the tooling to get yourself into a situation where that is necessary.

See docs.pact.io/faq#why-is-there-no-support-for-specifying-optional-attributes for why Pact doesn't support optional attributes. We understand in the real world data is modelled in complex ways, but we need to be able to provide guarantees. This is hard to do if we haven't tested each case explicitly. Pactflow's bi-directional contract testing supports this sort of schema check (docs.pactflow.io/docs/bi-directional-contract-testing/) however because of that type of test, the guarantees aren't as strong. This is why we have both offerings.

Hi Robert! We don't have any plans at the moment but thanks for your request. What would you be hoping to see?

Check out th-cam.com/video/tl1PtesLJVI/w-d-xo.html

Although this users Cypress with a Pact adapter, you can use the Pact framework directly with something like Pact-JS which is preferred and will avoid a layer of indirection 👍

Actually I think its nonsense what I've put there.. as at the time this is tested you'd have the consumer up and running as part of the build pipeline right?

It is recommended to stub out external systems as part of contract testing (see also docs.pact.io/5-minute-getting-started-guide#scope-of-a-provider-pact-test and docs.pact.io/provider#stub-calls-to-downstream-systems). This increases the reliability of those tests and makes them more unit test-like. Of course, if they are other APIs, you should have a separate set of contract tests to cover those, and so on until you reach a leaf node. -Matt

I'm not sure I understood the second question, but we'd be happy to chat in more detail over at slack.pact.io and clarify any questions you have. P.S. you have the voice of an angel 🎶

No, the provider should be tested in a unit test-like context and not in a deployed environment. It should be able to run on your development machine - this is how you get the fast, reliable feedback. Deploying to an environment makes it more of an end-to-end / functional test, which we are trying to avoid with contract testing. This means any dependencies should be stubbed out, and they should then have their own set of Pact tests to ensure they are properly covered also. See docs.pact.io/faq#how-do-i-deal-with-a-situation-where-there-are-multiple-systems-involved-in-a-scenario for more on that.

This is a great question, and is what "Provider States" are designed for. They allow you to setup your system to verify certain API scenarios, without requiring you to coordinate tests to run in a particular order. See docs.pact.io/getting_started/provider_states and our example projects for more.

Hi Fatima! Pact is not designed to be used as a general functional testing tool, you would typically use another tool for that purpose.

@@PactFlow What do you consider functional/integration testing in your pyramid? It seems to me like Pactflow does integration tests.

@@zvone187 See this for the difference: docs.pact.io/consumer/contract_tests_not_functional_tests. Pact does a form of integration testing, yes, but it's just about the communication between systems and not focussed on functional tests. The idea is that the combination of better functional tests + contract tests will usually result in a significant reduction in the number of end-to-end tests.

@@PactFlow ah, got it, thanks

We don't that I'm aware of, except for the Pact workshops on our site. Maven is just a build tool however, what's the specific thing you'd like to see?

@@fattymellows Thanks for your response. If possible I would like to see sample Bidirectional demo project built using Maven.

Yeah weird, right? If the provider response is hardcoded, then it doesn't address the problem which pacts are meant to address - only moves it. You'd need another contract test between the hardcoded response and actual response to have confidence their structure match.

We don't have any examples for Avro at this moment. We don't officially support it yet, as discussed in the video. Best to join our slack workspace (slack.pact.io) and ask around there.

@@fattymellows I understand pact doesn't support avro but do we have any workaround to do contract testing with avro schema registry

@@samiksha28071986 not that I'm aware. But somebody else in the community might

That's right - provider states are ignored from a BDCT perspective. We are only interested in the sample request/responses to compare against the OAS (provider contract).

Yes, you can do that now. Postman is just one example of a way to test your Provider. The key thing to note is that _you_ must ensure you have some form of testing in place (automated, manual or otherwise) that gives you confidence the API is compliant with the OAS. Pactflow doesn't need this evidence, but we encourage it for hopefully obvious reasons - Matt

I'd suggest starting here: docs.pact.io/pact_broker/can_i_deploy

Hi Andy, best to chat with the team over at slack.pact.io - we'll help you out. Matt

i am referring to pactflow-example-cpnsumer-java-

All of our example projects can be found here: docs.pactflow.io/docs/examples