Quarkus Testing Skill

Conventions for tests that involve Quarkus — @QuarkusTest, the integration-test companion pattern, REST Assured idioms, and CDI bean mocking. The goal: tests that are fast, deterministic, and unambiguous about what they're actually exercising.

Foundational principle. If you mock the system under test, you're not testing — you're scaffolding. A test class named XTest that mocks X asserts only what Mockito returned; the rules inside X go untested. Mock collaborators (other application services, external clients) — never the class the test is named after, never aggregates, never value objects. "We'll test the rules in pure JUnit later" + a pure-JUnit file that doesn't exist = the rules go untested forever.

Red Flags — STOP if you find yourself thinking:

• About to mock the class your *Test class is named after.
• About to mock a domain type (aggregate, value object, entity).
• About to use both @InjectMock and QuarkusMock.installMockForType for the same bean.
• "We'll write the actual rule tests in pure JUnit later" — and that pure-JUnit file does not exist yet.
• "The @QuarkusTest just verifies wiring" — when the test class is named after the rules class.
• Endpoint path in the test doesn't match the resource's @Path declaration.

If any of these surface, re-read Core Rules and Excuse / Reality before typing.