Skip to content

Let the setUp methods actually run - #587

Merged
slachiewicz merged 1 commit into
masterfrom
agent/run-the-orphaned-setup
Aug 10, 2026
Merged

Let the setUp methods actually run#587
slachiewicz merged 1 commit into
masterfrom
agent/run-the-orphaned-setup

Conversation

@slachiewicz

Copy link
Copy Markdown
Member

Follow-up to #584, where this turned up while debugging a Java 8 failure. It predates that PR and #583 — both methods were already unannotated before either.

Neither AbstractModelloGeneratorTest.setUp() nor its override in AbstractModelloJavaGeneratorTest carries @BeforeEach, so under Jupiter neither has been called at all. Both delete and recreate the test's output directory, so target/generator-results/<name> is never cleaned between runs and generated classes from an earlier run can survive into a later one and hide a failure. Those directories existed only because the compiler happened to create them — which is exactly how #584 surfaced it, since javax.tools on Java 8 will not create a -d that is missing.

Annotating is not quite enough on its own. The java override does not call super, so the sources directory would still go untouched; it now chains, and the two levels clean the two directories they each own.

AbstractStaxGeneratorTestCase existed only to add @BeforeEach and delegate to super.setUp() — the workaround for this bug, in the one place someone noticed the symptom. It is removed.

Evidence that it really was dead

Rather than argue from reading the code, I put an unconditional throw new IllegalStateException at the top of the base setUp() and ran the suite:

modello-plugin-java modello-plugin-xdoc
on master 17 tests, 0 errors 2 tests, 0 errors
with this change every test errors every test errors

A method that throws unconditionally cannot be executing. The second row also confirms both paths reach it: xdoc extends the base directly, java reaches it through the new super.setUp() chain.

Verification

mvn install with tests, every generator-results directory deleted first: exit 0, 120 tests, zero failures and zero errors across all 14 modules. spotless:check clean.

Use install or verify rather than mvn test here — see my comment on #584 for why mvn test reports 5 spurious NPEs on any branch.

Draft until CI confirms, jdk-8 included.

Generated-by: Claude Opus 5 (1M context)

Neither AbstractModelloGeneratorTest.setUp() nor its override in
AbstractModelloJavaGeneratorTest carried @beforeeach, so under JUnit
Jupiter neither was ever called. Both delete and recreate the test's output
directory, which meant target/generator-results/<name> was never cleaned
between runs and generated classes from an earlier run could survive into a
later one and hide a failure. The directories existed at all only because
the compiler happened to create them.

Annotating them is not quite enough on its own: the java override does not
call super, so the sources directory would still go untouched. It now
chains, and the two levels clean the two directories they each own.

AbstractStaxGeneratorTestCase existed only to add the annotation and
delegate to super - the workaround for this bug in the one place it was
noticed. It is no longer needed.

Verified by putting an unconditional throw at the top of the base setUp:
on master the affected modules still pass, which is only possible if the
method never runs; with this change the same probe fails every test that
inherits it, through both the direct and the chained path.

Generated-by: Claude Opus 5 (1M context)
@slachiewicz slachiewicz added java Pull requests that update Java code bug Something isn't working labels Aug 10, 2026
@slachiewicz
slachiewicz marked this pull request as ready for review August 10, 2026 00:41
@slachiewicz
slachiewicz merged commit 8ec845e into master Aug 10, 2026
12 checks passed
@slachiewicz
slachiewicz deleted the agent/run-the-orphaned-setup branch August 10, 2026 00:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working java Pull requests that update Java code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant