Hi all! Sorry, has contract testing to be made at same language of solution side?

I think you're asking if you create a contract in JS does it need to also be verified in JS? The answer to that question is no, they can be different. They in general should match the language of the code you are testing. E.g. if you have a react JS consumer, the tests should also be JS

Thank you. But imagine you have Consumer in JS and Provider in .NET. Can I build contract testing only with Java, for instance? (both sides)

It's not recommended. Pact should be thought of as a unit testing tool and used in that context

testing closest to the code, in the language the code is written in, will provide the shortest feedback loops and provide stronger guarantees that the mock expectations match reality, and are updated when the code under test is updated. Teams who don't will probably find overlap, your dev team will probably have component integration tests, where they are mocking code.

Indeed. I wonder if QA guys could go ahead with contract testing, but changing with one language to another is not easy. DEV need to help.

Pact is really a tool for Developers, or at least those that have access to the code base. I’ve never really seen it work well when done outside of the code base. It starts off looking ok, but then it becomes a maintenance issue as the system is evolved

In this way I saw Spring has modularized contrac testing solution. That could fit any language build in Java only.

Yes, but I’m not convinced you won’t run into the same problems listed above. It’s not a technology problem, it’s a people/organisation problem. When other teams write tests for other people’s code, the maintenance cost/pain is much higher. That’s not to say it’s not valuable, but usually the problem we’re trying to solve here is half created by that problem (the other half is the rest of the pain points associated with E2E tests). You might be interested in something like PactFlow’s bi-directional contract testing feature which is a lot more decoupled and alleviates many of these pain points, at the cost of being a bit less strict in terms of guarantees (see tradeoffs)

It would be more advisable for QA teams to look at the overlap of testing currently being performed, and the endpoints which are subject to change / fail often in integration tests, and work with the developers to advise about the value of contract testing, and utilise that in their codebases, as part of their unit testing strategy. This way you can avoid communication style errors pre deployment, leaving your integration tests to look at the useful business value normally spread out over multiple microservices, safe in the knowledge that each individual service can communicate with its dependants

One problem that appears is about who should test and this is already covered by many researches and, ok devs covering unit. helping with integration but not about e2e. I'm looking for pushing automation crew to contract tests. at some point I can but some limitations.

I’m looking for pushing automation crew to contract tests

what do you mean by this?

I'm looking for automation crew that write e2e tests to write contract testing as well.

I’m looking for automation crew that write e2e tests to write contract testing as well.

gotcha. As stated above, I would highly discourage doing the above. If you’re going to write Pact tests, the developers of the feature should write them. SDET’s are also acceptable if they are appropriately embedded, but again, these tests should be written along with the code being written e.g. TDD

Yes, we have access to the solution, but must of QAs are Java only. this is why I raised this thread. Thank you!