Testing

Testing QQQ 4.0

QQQ 4.0 release. Final 4.0.0 is available. See QQQ 4.0 for release scope and migration guidance.

Build and validate

Run mvn clean verify for your application. For the framework itself, run the complete root reactor and the separate sample build described in the Quickstart. Integration tests may need Docker and disposable database fixtures.

Validate the complete QInstance with QInstanceValidator. Set up an application-owned instance and session, initialize QContext before actions, and clear it after each test so thread-local state does not leak.

import com.kingsrook.qqq.backend.core.context.QContext;
import com.kingsrook.qqq.backend.core.instances.QInstanceValidator;

new QInstanceValidator().validate(qInstance);
QContext.init(qInstance, session);
try
{
   // Execute the action or process and assert its records and output values.
}
finally
{
   QContext.clear();
}

qInstance and session above are your configured fixtures. Framework TestUtils classes under src/test are examples, not a promised application dependency.

Useful checks

• Test allowed and denied access, validation failures, empty results, and persistence readback.
• Invoke BackendStep.run(input, output) with both objects and inspect the output.
• Exercise a full process to prove step wiring and selected-record behavior.
• Start the packaged server, request a real page or endpoint, and stop it in cleanup.
• Read generated reports and files instead of checking only that a file exists.

Keep mock or anonymous authentication confined to synthetic test data. Test the real authentication path before production deployment.

Framework release gates

Run the clean root build and the separate sample build from Building Locally. The configured Checkstyle rules and module-specific JaCoCo baselines are authoritative. Do not claim a coverage percentage from skipped tests or substitute a test-only run for verify/install gates.

Starter and template verification is separate. A QBit template must also be renamed/generated as a new project and consumed in a QRun-owned test host as required by its README. Core candidate acceptance exercises the exact published candidate in the QQQ sample and qqq-app-starter, using first-party configuration and disposable fixtures. Record QRun's acceptance evidence as described in Release Flow; local unit tests alone do not complete that gate.

For 4.0, the 48 source-coverage groups and separate published-stage train.bom coverage group (#627) are deferred under #534. The ledger reports those gaps; required release tests, BOM/artifact/signature verification and clean-cache public-artifact acceptance still apply.