AsyncAPI 3.x: the sampler

[LautaroPetaccio]

Eleventh in the AsyncAPI stack, on top of #1751. The fitness and the Guice module that make --problemType ASYNCAPI run come next.

What it does

At start-up, AsyncApiSampler asks the driver where the document is, reads it — from a location or as text, whichever AsyncApiProblem carried — hands it to AsyncApiActionBuilder, and ends up with one action template per publishable message. Whatever the parser or the builder had to skip is printed for the user and kept in the WarningsAggregator for the final report, as the REST sampler does.

Sampling is the plain kind: a random individual publishes between one and maxTestSize messages, each a copy of a template with its genes initialised. With smart sampling on, the first individuals handed out publish one message each, one per operation, so that every operation has been tried once before the search starts combining them — the same opening move as REST's ad-hoc individuals.

One sampler for both modes

REST and GraphQL have an initForBlackBox branch that fetches the schema themselves, because in black-box mode there is no driver. Here there always is one (#1751), so the document arrives the same way in both modes and the sampler never asks config.blackBox. One of the tests runs it with --blackBox=true and another with false, against the same fake driver, to hold that.

Not here

• The Guice module. A module needs a FitnessFunction binding before the injector it produces is usable, so AsyncApiModule arrives with the fitness, when it can be complete. Until then Main's ASYNCAPI branch keeps its message.
• Seeded test cases, which throw with a message saying they are not supported yet.

Testing

AsyncApiSamplerTest wires the sampler through Guice and Governator — so @PostConstruct runs for real — against a fake RemoteController that answers only what start-up asks. Ten tests: one action per operation of the NCS document; the same under --blackBox=true; the document fetched from a file the driver names; fifty random individuals within size bounds with every gene initialised and no setup actions; every operation tried once before combining, and again after resetSpecialInit(); what the parser had to skip reaching the WarningsAggregator for the final report; and three ways start-up can fail — a document that is not there, a service that does not start, a driver declaring no AsyncAPI service — each surfacing as a SutProblemException, which is what Main reports as a problem with the SUT rather than a crash.

All AsyncAPI core suites plus the config ones: 157 tests, 0 failures.