AsyncAPI 3.x: the fitness, and --problemType ASYNCAPI runs

[LautaroPetaccio]

Twelfth in the AsyncAPI stack, on top of #1752. With this one --problemType ASYNCAPI runs a whole search, everything but writing the tests.

What a search over an AsyncAPI service looks for

REST covers (status × endpoint). There are no status codes here, so the targets are:

• (outcome × operation) — what publishing to an operation was seen to do: PUBLISHED (fire-and-forget), REPLIED, or NO_REPLY.
• (declared reply × operation) — when a reply came back, which of the messages the contract declares for that reply it was. A reply channel that lists a result and an error gives the search two things to reach, and telling them apart is what makes an asynchronous service observable from outside.

Two things are faults (both @Experimental categories): a promised reply that never arrives, and a reply that matches none of the declared messages. A message the driver could not publish is neither — it is a broken setup, no target is registered for it, and the test stops there.

Recognising a reply

AsyncApiReplyClassifier matches the observed payload against each declared payload schema. It is deliberately a classifier, not a validator: it reads the parts of JSON Schema that tell one message from another — type (including type lists), required, const/enum, allOf/anyOf/oneOf, items, $ref to component schemas — and gives the benefit of the doubt on anything it does not understand (formats, bounds, patterns). When several declared messages fit, the most specific wins: the one pinning down the most top-level fields. No new dependency.

The fitness

AsyncApiBlackBoxFitness resolves everything the driver needs from the document — address, content type, correlation location and pointer, reply address, timeout — so the driver never reads the document. The correlation id is runId-counter, with runId drawn from Randomness, so a seeded run is reproducible and ids never repeat within a run. Headers travel as a map by way of the gene's own JSON printing, which is what knows which optional headers are on.

Not supported yet, and said so with a one-time warning: a reply address announced inside the request (reply.address.location) rather than fixed by the contract. Such an operation is published without waiting.

Plumbing

• RemoteController.executeNewAsyncApiActionAndGetReply, mirroring the RPC call. It has a default that throws, so the four other controllers (three of them test fakes) need not each say they cannot publish.
• EMConfig.asyncApiReplyTimeoutMs, @Experimental, default 5 s.
• A constraint: --createTests false is required for AsyncAPI until the test writer exists. Failing at start-up beats searching for an hour and failing at the end. TestCaseWriter is bound to the existing NoTestCaseWriter.
• AsyncApiModule, one for both modes, binding the driver unconditionally. It does not call super.configure(), like the RPC, GraphQL and Web modules: what EnterpriseModule binds there needs FitnessFunction<RestIndividual>.
• AsyncApiStructureMutator: one message more or one fewer. Unlike RPC's, it states its two bounds outright — a test keeps at least one message, and can grow to exactly maxTestSize — because mirroring RPC's arithmetic emptied a one-message test when maxTestSize was 2, and never let a test reach the maximum.
• Seeding test cases is refused at start-up too, for the same reason as writing them.
• Main's ASYNCAPI branch binds the module instead of throwing.

Testing

Three suites build the injector Main would, with the driver replaced by a fake, through one shared AsyncApiTestInjector.

• AsyncApiReplyClassifierTest (16): result vs error behind $refs, undeclared payloads, non-JSON, 3.0 is an integer, most-specific-wins, type lists; and, on a document written for the purpose, const through a chain of references, enum, oneOf/allOf/anyOf, array items, booleans vs their spelling, an unknown type name, and a reference into the middle of a schema being given the benefit of the doubt.
• AsyncApiBlackBoxFitnessTest (13): every DTO field the driver is told; unique correlation ids across evaluations; result and error as distinct targets; undeclared reply and silence as the two faults; fire-and-forget covered by PUBLISHED; headers as a map without the stamped one, structured headers as JSON; a correlation id located in the payload; a reply address announced at run time being published without waiting; a driver that could not publish, with and without saying why; a reply without its correlation id recorded rather than judged.
• AsyncApiStructureMutatorTest (4): the two bounds above, the maximum being reachable, added messages coming from the document, nothing happening when only one message is allowed. The first fails against RPC's arithmetic.
• AsyncApiModuleTest (1): a whole MIO search, 100 action evaluations, black-box, through the module Main binds, against a stand-in that answers like the NCS service. Asserts that every operation was answered, that some operation reached both its declared replies, that nothing was a fault, and that no correlation id repeated.

All AsyncAPI suites plus the config ones: 193 tests, 0 failures. jacoco over the AsyncAPI package: every new class above 90% line coverage.