perf(tests): one Dirigible boot per class for eight multi-method HTTP ITs - #6703
Merged
Conversation
… ITs IntegrationTest dirties the Spring context AFTER_EACH_TEST_METHOD, so a class with N methods boots the full runtime N times (~10-30s each). Override to AFTER_CLASS on the multi-method HTTP-level ITs whose methods already clean up after themselves - the pattern DatabaseFacadeIT has proven for a while (18 tests in 0.9s): IntentEngineIT (42), NumberingSdkIT (8), SecurityIT (7), DataStoreIT (7), JavaEngineIT (5), CmsAccessControlIT (5), IntentConversationIT (5), EndpointAuthorizationIT (5) 84 methods now cost 8 boots instead of 84. Measured on the CI baseline these classes took 907s of the api shard; two consecutive local runs of the converted batch complete in ~4:20 with all 84 tests green. Where sharing the database across methods needed honesty, it was added rather than assumed: SecurityUtil gains idempotent ensureUserInDefault- Tenant variants (a repeated plain create violates the unique user constraint once the context survives the method), CmsAccessControlIT revokes its READ grant after each test (a leaked grant breaks the 'open by default' premise the other tests start from), and EndpointAuthorizationIT switches its repeated per-method user creation to the idempotent variant. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
delchev
added a commit
that referenced
this pull request
Aug 13, 2026
#6708) Batch 2 of the AFTER_CLASS conversion (#6703 was batch 1): override @DirtiesContext to AFTER_CLASS on the remaining multi-method IT classes whose methods are read-only or clean up after themselves - audited class-by-class for shared-database honesty. 60 test methods now cost 22 boots instead of 60, trimming both the api and ui CI shards. Converted as-is (18): MonitoringPerspectiveIT, IntentBuilderShellIT, MonitoringShellIT, DatabaseShellIT, ShellSwitcherIT, EnabledMultitenantModeIT, CsvProcessorIT, RepositoryExportIT, CsvimReimportIT, DocumentsApiIT, JavaBpmnIT, JavaCamelIT, PerspectiveGroupAggregationIT, JavaCompilationProblemsIT, PrintRenderIT, ArtefactStatusEndpointIT, BpmnModelApiIT, TenantConfigurationIT. Converted with a state-honesty fix (4): - RestTransactionsIT: new @AfterEach drops TESTTABLE and deletes the committed test user - two methods otherwise collide on both. - IntentCrossModelScheduleSourceIT: cleanup force-syncs so the DELETE branch unschedules the published 5-second cron job, and the unpublish cleanup asserts a strict 2xx. - SynchronizerCleanupRaceIT: the cleanup sync runs unconditionally - the publish-bypass test leaves a registered JavaFile whose source is gone, which otherwise makes every later rebuild defer. - MessagingFacadeIT: the queue tests drain the now-persistent broker store before each method (FIFO and receive-timeout assertions need an empty queue). Deliberately NOT converted, with cause: MultitenancyHarmoniaIT (the fixture asserts absolute row counts and empty CMIS listings), LocalNativeAppLifecycleIT (leaks live OS processes and duplicate default-package FQNs between methods), SchemaExportImportIT (whole- SystemDB export tuned to a pristine database). Verified: two consecutive full runs of all 22 classes, fresh state each, 62/62 green both times. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This was referenced Aug 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
IntegrationTestcarries@DirtiesContext(classMode = AFTER_EACH_TEST_METHOD), so a class with N test methods boots the full Dirigible runtime N times. Across the suite that is 275 boots for 116 classes — ~41 minutes of pure Spring startup per CI leg (measured on run 31679871168). Follow-up to #6702, which sharded the jobs; this shrinks the biggest shard's actual compute.Change
Override to
@DirtiesContext(AFTER_CLASS)on the eight multi-method HTTP-level ITs whose methods already clean up after themselves — the patternDatabaseFacadeIThas proven for a while (18 tests in 0.9s):IntentEngineITNumberingSdkITSecurityITDataStoreITJavaEngineITCmsAccessControlITIntentConversationITEndpointAuthorizationIT84 methods now cost 8 boots instead of 84 (~10 min off the
apishard).Where sharing the database across methods needed honesty, it was added rather than assumed:
SecurityUtilgains idempotentensureUserInDefaultTenantvariants — once the context survives the method, a repeated plain create violates the unique user constraint.CmsAccessControlITrevokes its READ grant in a new@AfterEach— a leaked grant breaks the "open by default — no rule exists" premise the other tests start from — and its user setup becomes idempotent.EndpointAuthorizationITswitches its repeated per-method user creation to the idempotent variant.The remaining six classes keep only the annotation:
IntentEngineIT,JavaEngineIT,IntentConversationITandNumberingSdkITalready have honest@AfterEachcleanup;DataStoreITrecreates its tables in@BeforeEach;SecurityITis read-only (MockMvc +@WithMockUser).NumberingSdkIT's assertions were audited for counter persistence: they are all relative (b == a+1), explicitly seeded, or use partition names unique to their method — consistent with the engine's own "counters are never reset" contract.Deliberately NOT converted (candidates for a later batch, each needs its own analysis):
LocalNativeAppLifecycleIT(OS process lifecycle),EnabledMultitenantModeIT(tenant provisioning), and the UI classes.Verification
target/dirigibleeach): 84/84 green, ~4:20 per run (the repeatability check theSecurityIT/System changelog: per-changeset MARK_RAN guards fix the SecurityIT smoke flake #6661 lesson calls for — leaked state shows up on the second run).mvn formatter:validategreen on both modules;mvn -P releasejavadoc check green ontests-framework(new public methods carry Javadoc).🤖 Generated with Claude Code