quarkiverse / quarkus-pact

Pact is a widely-recommended framework for consumer-driven contract testing. This Quarkus extension gives the best Pact integration with Quarkus.

quarkus-pact

Pact Support for Quarkus

provider:   consumer:

Pact is a polyglot contract testing framework. You can read more about it here: https://pact.io/ This extension ensures Pact works will with Quarkus applications, including with continuous testing.

To get started, add the dependencies. Choose a 1.x version for Quarkus 3, and a 0.x version for Quarkus 2.

Provider tests

    <dependency>
      <groupId>io.quarkiverse.pact</groupId>
      <artifactId>quarkus-pact-provider</artifactId>
      <version>LATEST</version>
      <scope>test</scope>
    </dependency>

Consumer tests

    <dependency>
      <groupId>io.quarkiverse.pact</groupId>
      <artifactId>quarkus-pact-consumer</artifactId>
      <version>LATEST</version>
      <scope>test</scope>
    </dependency>

Features

Continuous testing/dev mode

This extension allows Pact contract tests to run with mvn quarkus:dev and mvn quarkus:test.

Samples and resources

• Introduction to Pact
• How to use Pact's Java library
• Quarkus Superheroes sample
• Eric Deandrea and Holly Cummins recently spoke about contract testing with Pact and used the Quarkus Superheroes for their demos. Watch the replay and view the slides if you'd like to learn more about contract testing.

Contributors ✨

Thanks goes to these wonderful people (emoji key):

Holly Cummins 💻 🚧

Michal Vavřík 📖

Nicolas Filotto 💻

This project follows the all-contributors specification. Contributions of any kind welcome!

quarkus-pact's Issues

Only request/response interactions can be used with an HTTP test target

Hello everyone

I have created a contract from the message consumer:

Now I would like to have it checked the produced messages.

For that I wrote following Test:

@QuarkusTest
@TestProfile(SignatureTestProfile.class)
@Provider("SignPdfProvider")
@Consumer("signPdfConsumer")
@PactFolder("pacts")
public class SignPdfJmsProviderContractTest {


    @Inject
    Messageproducer messageproducer;

    @PactVerifyProvider("a signPdfRequest Message")
    void testASignPdfRequestMessage(PactVerificationContext context) {
        context.verifyInteraction();
        messageproducer.produceMessage();
    }

    @TestTemplate
    @ExtendWith(PactVerificationInvocationContextProvider.class)
    void pactVerificationTestTemplate(PactVerificationContext context) {
        context.verifyInteraction();
    }
}

However, I get the following error message:

java.lang.UnsupportedOperationException: Only request/response interactions can be used with an HTTP test target at au.com.dius.pact.provider.junit5.HttpTestTarget.prepareRequest(TestTarget.kt:98) at au.com.dius.pact.provider.junit5.PactVerificationExtension.beforeTestExecution(PactVerificationExtension.kt:136) at org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeBeforeTestExecutionCallbacks$5(TestMethodTestDescriptor.java:191)

Dependencies:

• quarkus-pact-provider: 1.1.0
• Quarkus: 2.16.12.Final

Many thanks for your support

Tests for io.quarkus.test.common.http.TestHTTPEndpoint

Following the Quarkus testing guide, we should add some tests that use io.quarkus.test.common.http.TestHTTPEndpoint, and make sure they work.

(We should also consider whether other samples want to be updated to model this.)

Resolve issues updating to Pact 4.4.x

Pact 4.4.x introduces a few problems:

• @knutwannheden observes that 4.4.0 introduces Groovy 4, and this may be problematic when used together with other Groovy-based frameworks like Rest-Assured for example.
• Although 4.4.1 and 4.4.2 built cleanly, 4.4.3 introduces a test failure (see #45):

2023-01-05 18:24:15,719 ERROR [io.qua.test] (Test runner thread) >>>>>>>>>>>>>>>>>>>> Summary: <<<<<<<<<<<<<<<<<<<<
FarmContractTest#pactVerificationTestTemplate(PactVerificationContext) java.lang.NoClassDefFoundError: org/apache/commons/text/translate/AggregateTranslator
2023-01-05 18:24:15,721 ERROR [io.qua.test] (Test runner thread) >>>>>>>>>>>>>>>>>>>> 0 TESTS FAILED <<<<<<<<<<<<<<<<<<<<
0 tests failed (1 passing, 0 skipped), 1 test was run in 4544ms. Tests completed at 18:24:15.

This may be caused by a new dependency which needs to be declared parent first.

Friendly magic - eliminate the need to @BeforeEach a context.setTarget(new HttpTestTarget("localhost", 8081))

We can elimiminate some boilerplate, as we do for other extensions like rest-assured.

At the moment, every provider tests need boilerplate like the following:

    @ConfigProperty(name = "quarkus.http.test-port")
    int quarkusPort;


    @BeforeEach
    void beforeEach(PactVerificationContext context) {
        context.setTarget(new HttpTestTarget("localhost", this.quarkusPort));
        [...]

In a @QuarkusTest, there's only one set of values for the host and port, so we should do that context initialisation automatically.

Tests for other transport protocols like messaging and gRPC

Continuous testing should retrigger if a pactfolder has a new changes

I think quarkusio/quarkus#32980 should make this easy.

Refactor tests to reduce duplication

At the moment, for both provider and consumer, the tests have the test methods and sample code duplicated 2-4 times. For example, the test methods are in a normal mode deployment test, a dev mode deployment test, a normal mode integration test, and a dev mode integration test.

We should be able to reduce this duplication. Inheritance is an obvious option, but may not be the right one, for the reasons described in https://www.petrikainulainen.net/programming/unit-testing/3-reasons-why-we-should-not-use-inheritance-in-our-tests/ and https://medium.com/decisionbrain/factor-test-code-the-junit-5-way-that-is-without-inheritance-9ba2784d34 - but annotations might significantly affect the running of the tests, given that annotations are a major cause of problems in this context. So it needs thought.

Quarkus-style configuration of pact location and broker

We should make sure things set in application.properties are made available to the tests.

This is related to #3, but different enough that it should get its own issue. The other issue is about enabling dynamic behaviour in the annotation, this is about more general quarkus-friendly config, as we do for many other extensions.

Dev UI view of contract contents and status

This would be nice, but we don't want to rewrite a pact broker.

Maybe a mini-broker which read files locally could be incorporated, or perhaps we should just give a window through to a configured broker where one is available.

OutOfMemoryError running cross-extension integration tests with Quarkus 3.7 +

This is causing the current failures on quarkiverse/quarkiverse#94, and it's also blocking any update to Quarkus 3.7.

2024-02-15 12:35:50,970 INFO  [io.qua.dep.dev.IsolatedDevModeMain] (main) Attempting to start live reload endpoint to recover from previous Quarkus startup failure
2024-02-15 12:35:51,199 ERROR [io.qua.dep.dev.IsolatedDevModeMain] (main) Failed to start quarkus: java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
        [error]: Build step io.quarkus.deployment.dev.testing.TestTracingProcessor#startTesting threw an exception: java.lang.OutOfMemoryError: Java heap space
        at java.base/java.lang.Object.clone(Native Method)
        at org.apache.maven.model.ModelBase.clone(ModelBase.java:218)
        at org.apache.maven.model.Profile.clone(Profile.java:60)
        at org.apache.maven.model.Model.clone(Model.java:356)
        at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:292)
        at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:243)
        at io.quarkus.bootstrap.resolver.maven.MavenModelBuilder.build(MavenModelBuilder.java:63)
        at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:284)
        at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:175)
        at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor(DfDependencyCollector.java:382)
        at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult(DfDependencyCollector.java:368)
        at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:218)

The failure can be avoided by disabling the DevModeContractTestIT in the cross-extension project.

QuarkusTestProfile does not work in dev mode

See super-heroes application for an example.

Diagnosing consumer failures is really hard

When a consumer test fails, the only error message tends to be an opaque the method annotated with @Pact did not run message. This makes diagnosing the underlying cause very hard.

There are several sub-problems.

Diagnosing absence

This is a fundamental Pact issue. If something didn't happen (the tests didn't hit the expected endpoint), it's hard to know what we can tell the user that's helpful. Monitoring all traffic and reporting what did happen would help, but it's not trivial. The wording of the error message maybe could be improved, but it's hard to see an obvious solution beyond that.

Maybe Quarkus can use its knowledge of the stack to monitor outbound traffic more easily than base Pact can.

Over-long stack traces

I don't think it's necessary to get the stack trace for the Pact failure, since it doesn't help us diagnose things.

Suppressed error messages

This is unique to continuous testing. And bad. For some errors, like a class not found, we get a helpful message with mvn verify, but not with continuous testing. Somehow in CT the error message gets swallowed.

Missing diagnostics for global issues

For some issues, breaking the tests is 'global' and seems to affect the whole runtime. For example, with #58, having one annotation will break all pact tests. In these cases, we don't get any messages at all (although in normal mode the tests run, so it's hard to compare.)

Extreme syntactic sugar - allow tests to use same model as we do for rest clients

When we define a rest client mock, the suggested pattern is this:

    @InjectMock
    @RestClient
    Client mock;

    @BeforeEach
    public void setUp() {
        when(mock.get()).thenReturn("MockAnswer");
    }

It would be nice to be able to do something similar for Pact, something like:

    @InjectPactMock
    @RestClient
    Client contractMock;

    @BeforeEach
    public void setUp() {
        when(contractMock.get()).thenReturn("MockAnswer");
    }

(Or perhaps it would still be in a @Pact block, but as concise.)

The current pattern is much more verbose, and almost all of the content (ports, content type headers, endpoints, schema for return and input parameters ... ) is in there is already in the RestClient definition:

    @Pact(provider = "farmer", consumer = "knitter")
    public V4Pact createPact(PactDslWithProvider builder) throws JsonProcessingException {
        Map<String, String> headers = new HashMap<>();
        headers.put("Content-Type", "application/json");

        // Here we define our mock, which is also our expectations for the provider
        String sweaterBody = "{\"colour\":\"white\"}\n";
        return builder.given("test POST")
                .uponReceiving("POST REQUEST")
                .path("/wool/order")
                .method("POST")
                .willRespondWith()
                .status(200)
                .headers(headers)
                .body(sweaterBody)
                .toPact(V4Pact.class);
    }

Things that aren't in the client that would need to be defined in the equivalent of when(contractMock.get()).thenReturn("MockAnswer") are the various states (given), and the response values.

Pact consumer tests do not work correctly in dev mode

See also #11. Sadly, the fixes to make provider tests work in dev mode are not sufficient to make consumer tests work in dev mode.

first release in maven repo?

Hello @holly-cummins ,

when do you plan to have a first release in maven central repo?

Best Regards
Alex

Continuous testing reruns can give different results from 'fresh' run

When debugging #58, I've noticed that if I add or remove a problem annotation, or disable and enable tests, the new tests will run, but the results aren't accurate – that is, they're different from what I'd get if I stopped and restarted.

I assume the issue is that some global state is being changed on startup, and that's what causes #58, and that also causes this. The two fixes may be the same, but tracking both issues separately to make sure it's resolved.

@TestProfile does not work in dev mode

@TestProfile annotations seem to disrupt the pact mechanism, when run in continuous testing.

I've observed it for consumer tests, and assume it is similar with provider tests. I suspect @QuarkusTestResource may have a similar problem, but haven't checked yet.

Note that the problem doesn't necessarily show with continuous testing (ironically): the tests may need to be stopped and restart for tests to fail (or to start passing if the annotation is removed). I've raised #59 for this.

com.ctc.wstx.stax.WstxOutputFactory not found when using Pact Provider

Hi!

When we are using the Pact Provider and it works great while we develop and run our microservice local, but when we run it in an image at Openshift, we get this error massage:

Caused by: javax.xml.stream.FactoryConfigurationError: Provider com.ctc.wstx.stax.WstxOutputFactory not found
at javax.xml.stream.XMLOutputFactory.newInstance(Unknown Source)

If we remove the Pact provider dependency, it will start working.

Quarkus version: 2.15.0-Final, have tried the 2.16.3-Final with the same result.

Better offline behaviour for provider with Pact broker

When writing a Pact test, a provider needs to specify a source for contracts using annotations on the test. The source can be either a local directory, or a broker. It's awkward to have to change the annotations to switch from the broker to running locally. This feels like the sort of scenario where a dev service might be useful.

It's not trivial, though, because a dev service would need a source of 'real' contracts.

We could either:

• Cache contracts when running with the broker, and then use them in offline mode
• Configure a dev service to point to a local source of contracts

The second option works great for demos, but I'm not sure how useful it would be for realistic development.

The first option may be more useful, but it's not a perfect fit for the semantics of a dev service. Normally we'd configure credentials for production, and not for dev, and then a dev service would be invoked. Here the behaviour change wouldn't be prod vs dev, but online vs offline.

Allow pact classloading configuration to be removed from quarkus core by having it here

This is something we want to think about. The main Quarkus product declares some pact libraries to be parentFirst.

Should we move all that configuration over here? It would mean the extension was required for pact, but would make the main codebase tidier.

       <!-- Pact[<4.1.0] support. It would be great if there was somewhere better to put this-->
                        <parentFirstArtifact>au.com.dius:pact-jvm-provider-junit5</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius:pact-jvm-provider</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius:pact-jvm-core-support</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius:pact-jvm-core-pact-broker</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius:pact-jvm-core-model</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius:pact-jvm-core-matchers</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius:pact-jvm-junit5</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius:pact-jvm-consumer-java8</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius:pact-jvm-consumer</parentFirstArtifact>
                        <!-- Pact[>=4.1.0] support.-->
                        <parentFirstArtifact>au.com.dius.pact.provider:junit5</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius.pact:provider</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius.pact.core:support</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius.pact.core:pactbroker</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius.pact.core:model</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius.pact.core:matcher</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius.pact.consumer:junit5</parentFirstArtifact>
                        <parentFirstArtifact>au.com.dius.pact:consumer</parentFirstArtifact>

CLI plugin for publishing pacts

More test samples and support for passing objects in on pact construction

At the moment, the consumer test does the following:

    private static final String alpacaBody = " {\n" +
            "      \"colour\": \"black\",\n" +
            "          \"name\": \"floppy\"\n" +
            "        }";

...

        // Here we define our mock, which is also our expectations for the provider

        return builder.given("test GET")
                .uponReceiving("GET REQUEST")
                .path("/alpaca")
                .method("GET")
                .willRespondWith()
                .status(200)
                .headers(headers)
                .body(alpacaBody)
                .toPact(V4Pact.class);

That should always work, but it would be nice to be able to do

    private static final Alpaca alpaca = new Alpaca("black", "floppy");

...

        // Here we define our mock, which is also our expectations for the provider

        return builder.given("test GET")
                .uponReceiving("GET REQUEST")
                .path("/alpaca")
                .method("GET")
                .willRespondWith()
                .status(200)
                .headers(headers)
                .body(alpaca)
                .toPact(V4Pact.class);

That works with Rest Assured. This would probably be a change to feed back to the Pact library, perhaps by allowing it to be initialised with an object mapper and then us auto-magically handing over the object mapper?

Alternatively, we should include some tests which manually inject the object mapper and create the json. There's no extension-specific magic, but it's a useful example to be able to follow.

Metrics exceptions in `quarkus:test`

When running in quarkus:test mode, some classes needed for pact metrics are missing. The stack traces are harmless, but annoying. We could either fill in the dependency, or disable metrics in that mode.

Exception in thread "Thread-226" java.lang.NoClassDefFoundError: org/apache/hc/client5/http/fluent/Request

        at au.com.dius.pact.core.support.Metrics.sendMetrics$lambda-2(Metrics.kt:124)
        at java.base/java.lang.Thread.run(Thread.java:833)

Instructions for disabling the metrics are:

2023-02-08 12:00:02,092 WARN  [au.com.diu.pac.cor.sup.Metrics] (Thread-61) 
            Please note: we are tracking events anonymously to gather important usage statistics like JVM version
            and operating system. To disable tracking, set the 'pact_do_not_track' system property or environment
            variable to 'true'.

1.2.0 -> 1.3.0 causing class not found errors

It seems the upgrade from 1.2.0 to 1.3.0 is causing some class not found errors?

See https://github.com/quarkusio/quarkus-super-heroes/actions/runs/8109821111/job/22165814968#step:4:4739

Pact provider tests do not work correctly in dev mode

Dev mode behaviour has been improved by pact-foundation/pact-jvm#1607, but it also needs some changes to pull more of the classpath to be parent first.

Syntactic sugar - allow easier config of @PactTestFor(providerName = "farmer", port = "8084")

Instead of writing

@PactTestFor(providerName = "farmer", port = "8084")

it would be nice to be able to provide a rest client config key (similar to what we set in @RegisterRestClient(configKey = "farmer-api"). That would give us the URL and should also allow us to work out a sensible default provider name.

Alternatively, we pass through a class name of a RestClient, just as we do with some other Quarkus tests.

Use web hook (or some equivalent mechanism) to trigger dev-mode test re-run on broker update

At the moment, if tests in a broker change, we don't automatically re-run tests in dev mode. There is a web hook, so we should be able to re-trigger test run. This would be extra-nice when running with the dev service, but also generally useful.

Continuous testing should retrigger if a pact broker has a new contract

At the moment, if tests in a broker change, we don't automatically re-run tests in dev mode. There is a web hook, so we should be able to re-trigger a test run. This would be extra-nice when running with the dev service, but also generally useful.

Here's what needs to happen:

• For testing the extension itself, we would want a dev service (#4)
• Read the Pact broker coordinates from config or from the pact files
• Decide if we have any provider tests using a broker
• In the case where the Pact Broker is external, use ngrok or equivalent to get an externally accessible URL
• Register with the Pact Broker web hook, following the instructions on https://docs.pact.io/pact_broker/webhooks#using-webhooks-with-the-contract_requiring_verification_published-event
• In our REST endpoint, trigger a test re-run

Add tests for provider and consumer in same project

This is a realistic scenario, and with such complex classloading, it's also possible it might fail.

Unable to resolve au.com.dius.pact.provider:junit5:4.5.6

I am trying to use io.quarkiverse.pact:quarkus-pact-provider:1.0.0.Final on my quarkus project and am running into the following error

> Task :quarkusGenerateCode FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':quarkusGenerateCode'.
> Could not resolve all files for configuration ':quarkusProdBaseRuntimeClasspathConfiguration'.
   > Could not resolve au.com.dius.pact.provider:junit5:4.5.6.
     Required by:
         project : > io.quarkiverse.pact:quarkus-pact-provider:1.0.0.Final
      > java.lang.NullPointerException (no error message)

Upstream changes in Quarkus leads to failure for a message with a payload

This could be invalid as I do run tests with released Quarkus Pact (tried it also with 1.3.0) and Quarkus 999-SNAPSHOT and without changing anything in my tests, or changing Quarkus Pact version, I now get tests failing (looks like started in last days).

Verifying a pact between TheConsumer and TheProvider
  [Using File src/test/resources/pacts/TheConsumer-TheProvider.json]
  a message with a payload
      Verification Failed - No annotated methods were found for interaction 'a message with a payload'. You need to provide a method annotated with @PactVerifyProvider("a message with a payload") on the classpath that returns the message contents.

Failures:

1) a message with a payload

    1.1) No annotated methods were found for interaction 'a message with a payload'. You need to provide a method annotated with @PactVerifyProvider("a message with a payload") on the classpath that returns the message contents.

Is this something that will be fixed with the next Pact version or a known issue?

Steps to reproduce:

1. git clone [email protected]:quarkus-qe/quarkus-test-suite.git
2. cd quarkus-test-suite
3. mvn clean test -f test-tooling/pact/

Upgrade to Quarkus 3.3.0 breaks provider verification tests

I upgraded https://github.com/edeandrea/pact-quarkus-wookie-carpet-demo/tree/wookie/wookie-tamer to Quarkus 3.3.2 and when introducing the contract verification tests that pull from the pact broker I am seeing this stack trace in the console:

2023-09-12 15:44:53,541 ERROR [io.qua.test] (Test runner thread) Test FurResourceContractVerificationTests#Pact between weaver (1.0) and wookie-tamer - A request for wookie fur failed 
: java.lang.NoClassDefFoundError: groovy/lang/Closure
        at au.com.dius.pact.provider.ProviderClient$Companion.invokeIfClosure(ProviderClient.kt:261)
        at au.com.dius.pact.provider.ProviderClient$Companion.access$invokeIfClosure(ProviderClient.kt:252)
        at au.com.dius.pact.provider.ProviderClient.newRequest(ProviderClient.kt:478)
        at au.com.dius.pact.provider.ProviderClient.prepareRequest(ProviderClient.kt:304)
        at au.com.dius.pact.provider.junit5.HttpTestTarget.prepareRequest(TestTarget.kt:96)
        at au.com.dius.pact.provider.junit5.PactVerificationExtension.beforeTestExecution(PactVerificationExtension.kt:136)

I tried backing down to Quarkus 3.3.1 and 3.3.0 but see the same error. When I go to 3.2.5.Final everything works fine.

The test class is https://github.com/edeandrea/pact-quarkus-wookie-carpet-demo/blob/wookie/wookie-tamer/src/test/java/org/wookie/tamer/FurResourceContractVerificationTests.java but removing the @PactFolder("pacts") annotation & uncommenting the other 2 annotations on the class.

Interestingly, running the verification tests when using a local folder containing the pacts seems to be fine.

@State methods do not not have access to the CDI context

This was discovered by @edeandrea.

This may need a Quarkus change - or be impossible to fix - but this issue can track the investigation. I assume this is a classloader issue, because in https://github.com/beforeeach methods we have access to the CDI context, but in https://github.com/State methods, we don't - even though it would be very useful in those methods.

pact-foundation/pact-jvm#1604 (comment) has sample code showing the issue.

Resolve incompatibility in Antlr versions between Pact 4.3.15 and Quarkus < 2.1.16

Upgrading Pact from 4.3.14 to 4.3.15 the tests no longer run and result in a failure with Antlr. The root cause is that Antlr changed their ATN format between 4.9.2 and 4.10, and Pact 4.3.15 brings in Antlr 4.11. This would be ok, except that Quarkus uses Antlr 4.9.2, and having the two versions of Antlr on the classpath causes ATN conflicts.

See pact-foundation/pact-jvm#1615.

See also pact-foundation/pact-jvm#1380, except in the other direction (Quarkus's pact is too old, rather than too new). I'm also looking at quarkusio/quarkus#27298, which is a Quarkus PR to upgrade Quarkus's Antlr from 4.9.2 to a higher version. There's some discussion of Pact on that work item. I think the incompatible Antlr must be sneaking into the user test classpath from Quarkus.

ANTLR Tool version 4.11.1 used for code generation does not match the current runtime version 4.9.2
ANTLR Runtime version 4.11.1 used for parser compilation does not match the current runtime version 4.9.2
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 8.884 s <<< FAILURE! - in io.quarkus.sample.superheroes.villain.ContractVerificationTests
[ERROR] io.quarkus.sample.superheroes.villain.ContractVerificationTests.pactVerificationTestTemplate(PactVerificationContext)  Time elapsed: 8.88 s  <<< ERROR!
java.lang.RuntimeException: java.lang.ExceptionInInitializerError
        at au.com.dius.pact.core.support.KotlinLanguageSupportKt.handleWith(KotlinLanguageSupport.kt:44)
        at au.com.dius.pact.provider.junit5.PactVerificationInvocationContextProvider.resolvePactSources(PactJUnit5VerificationProvider.kt:84)
        at au.com.dius.pact.provider.junit5.PactVerificationInvocationContextProvider.provideTestTemplateInvocationContexts(PactJUnit5VerificationProvider.kt:45)
        at org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.lambda$execute$0(TestTemplateTestDescriptor.java:106)
        at java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:273)
        at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
        at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
        at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
        at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
        at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
        at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
        at org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:110)
        at org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:44)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
        at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
        at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
        at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
        at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
        at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
        at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
        at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
        at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
        at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
        at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
        at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
        at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
        at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
        at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:35)
        at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57)
        at org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:54)
        at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:147)
        at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:127)
        at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:90)
        at org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:55)
        at org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:102)
        at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:54)
        at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:114)
        at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:86)
        at org.junit.platform.launcher.core.DefaultLauncherSession$DelegatingLauncher.execute(DefaultLauncherSession.java:86)
        at org.apache.maven.surefire.junitplatform.LazyLauncher.execute(LazyLauncher.java:55)
        at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.execute(JUnitPlatformProvider.java:223)
        at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.invokeAllTests(JUnitPlatformProvider.java:175)
        at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.invoke(JUnitPlatformProvider.java:139)
        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:456)
        at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:169)
        at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:595)
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:581)
Caused by: java.lang.ExceptionInInitializerError
        at au.com.dius.pact.core.support.Version.parse(Version.java:79)
        at au.com.dius.pact.core.model.DefaultPactReader.pactFromJson(PactReader.kt:219)
        at au.com.dius.pact.core.model.DefaultPactReader.loadPact(PactReader.kt:214)
        at au.com.dius.pact.provider.junitsupport.loader.PactBrokerLoader.loadPactsForProvider(PactBrokerLoader.kt:268)
        at au.com.dius.pact.provider.junitsupport.loader.PactBrokerLoader.load(PactBrokerLoader.kt:130)
        at au.com.dius.pact.provider.junit5.PactVerificationInvocationContextProvider$resolvePactSources$pactSources$1$pacts$1.invoke(PactJUnit5VerificationProvider.kt:84)
        at au.com.dius.pact.core.support.KotlinLanguageSupportKt.handleWith(KotlinLanguageSupport.kt:39)
        ... 61 more
Caused by: java.lang.UnsupportedOperationException: java.io.InvalidClassException: org.antlr.v4.runtime.atn.ATN; Could not deserialize ATN with version 4 (expected 3).
        at org.antlr.v4.runtime.atn.ATNDeserializer.deserialize(ATNDeserializer.java:187)
        at au.com.dius.pact.core.support.VersionLexer.<clinit>(VersionLexer.java:121)
        ... 68 more
Caused by: java.io.InvalidClassException: org.antlr.v4.runtime.atn.ATN; Could not deserialize ATN with version 4 (expected 3).
        ... 70 more

08:19:16 INFO  [io.qu.sa.su.vi.VillainApplicationLifeCycle] (main) The application VILLAIN is stopping...
08:19:16 INFO  [io.quarkus] (main) rest-villains stopped in 0.019s
[INFO] 
[INFO] Results:
[INFO] 
[ERROR] Errors: 
[ERROR]   ContractVerificationTests.pactVerificationTestTemplate(PactVerificationContext) » Runtime java.lang.ExceptionInInitializerError
[INFO] 
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0

Ecosystem CI tests failing because of platform dependencies in integration tests

Some of the integration tests depend on quarkus platform, rather than just quarkus. This is annoying when trying to run locally against a snapshot build, and it's also causing failures in the ecosystem CI (see, for example, https://github.com/quarkiverse/quarkus-pact/actions/runs/4160309746/jobs/7197179102):

2023-02-13T06:30:22.5397530Z [INFO] Running io.quarkiverse.pact.it.TestModeContractTestIT
2023-02-13T06:30:24.3382043Z [INFO] Scanning for projects...
2023-02-13T06:30:24.4858900Z [WARNING] The POM for io.quarkus.platform:quarkus-maven-plugin:jar:2.16.999-SNAPSHOT is missing, no dependency information available
2023-02-13T06:30:24.5232321Z [ERROR] [ERROR] Some problems were encountered while processing the POMs:
2023-02-13T06:30:24.5234310Z [ERROR] Unresolveable build extension: Plugin io.quarkus.platform:quarkus-maven-plugin:2.16.999-SNAPSHOT or one of its dependencies could not be resolved: io.quarkus.platform:quarkus-maven-plugin:jar:2.16.999-SNAPSHOT was not found in https://oss.sonatype.org/content/repositories/snapshots during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of snapshots-repo has elapsed or updates are forced @ 
2023-02-13T06:30:24.5236172Z [ERROR] Non-resolvable import POM: io.quarkus.platform:quarkus-bom:pom:2.16.999-SNAPSHOT was not found in https://oss.sonatype.org/content/repositories/snapshots during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of snapshots-repo has elapsed or updates are forced @ line 21, column 19

Quarkus 3 - consumer tests cannot directly access pact `MockServer` in test methods in dev mode

With the switch to Quarkus 3, we've moved to running more of the Pact infrastructure in the Quarkus classloader, rather than the system one. One side effect of this is that direct access to the pact MockServer gives classloading conversion errors (on Java 17 and higher):

---- Debugging information ----
message             : No converter available
type                : java.util.concurrent.CopyOnWriteArrayList
converter           : com.thoughtworks.xstream.converters.reflection.SerializableConverter
message[1]          : Unable to make private void java.util.concurrent.CopyOnWriteArrayList.readObject(java.io.ObjectInputStream) throws java.io.IOException,java.lang.ClassNotFoundException accessible: module java.base does not "opens java.util.concurrent" to unnamed module @5eff30f4
converter[1]        : com.thoughtworks.xstream.converters.reflection.ReflectionConverter
message[2]          : Unable to make field private static final long java.util.concurrent.CopyOnWriteArrayList.serialVersionUID accessible: module java.base does not "opens java.util.concurrent" to unnamed module @5eff30f4
-------------------------------

Here is an example of a problematic access:

    public void testPortIsCorrect(MockServer mockServer) {

In general, test code should have no reason to access the mockServer directly, because the consumer tests should be testing the consumer, not the mock. The access here was to actually try and test the pact extension.

Because of that, I believe this is a low priority issue.

Allow Quarkus config to be used in @PactTestFor

This would allow us to set ports to be the configured ports, for example.

It's non-trivial, because we need to persuade IDE compilers to allow it.

Contract tests do not run in dev mode if scope is `test` (provider and consumer both)

The natural scope of the pact extension is test, but if we set the scope to test, tests pass with mvn verify, but they don't pass with mvn quarkus:dev.

This may need a Quarkus change to fix, and it may be quite hard to fix.

Closure cannot be found when upgrading to Quarkus 3.3

The platform build fails with ClassNotFoundException: groovy.lang.Closure due to quarkusio/quarkus#34447