Skip to content

Conversation

@Pankraz76
Copy link
Contributor

@Pankraz76 Pankraz76 commented May 8, 2025

Pull #2304: Modernize codebase with Java improvements - test DefaultModelProcessor#read

enable for:

100 as everything else is enough for a tremendous project like maven:

image

Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor-test branch from 25dbfc7 to 0482492 Compare May 8, 2025 06:43
@Pankraz76 Pankraz76 changed the title Pull #2292: Modernize codebase with Java improvements - test DefaultModelProcessor#read Modernize codebase with Java improvements - test DefaultModelProcessor#read May 8, 2025
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor-test branch from 0482492 to 542101a Compare May 8, 2025 06:43
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor-test branch from 542101a to 7ed0ace Compare May 8, 2025 07:18
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor-test branch from 7ed0ace to e46da18 Compare May 8, 2025 07:33
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor-test branch from e46da18 to 02b5deb Compare May 8, 2025 07:42
@Pankraz76 Pankraz76 marked this pull request as ready for review May 8, 2025 07:48
@Pankraz76
Copy link
Contributor Author

this one important to give liberty on code back to us; making code liquide while logic remains tight and dusty.

@Pankraz76
Copy link
Contributor Author

Pankraz76 commented May 8, 2025

ideally when merging this, the test will be obsolet in follow up, allowing any adjustment:

then we have awareness that coverage is a real deal and not a nice gimmick.

Kindly request your feedback @gnodet @elharo.

return project;
}

private Model doRead(XmlReaderRequest request) throws IOException {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is wrong/counterfeit because:

Currently, the API is designed to throw XmlReaderException. Check the implemented interface, there's no IOException thrown here.

#2292 (comment)

} catch (IOException e) {
exceptions.forEach(e::addSuppressed);
throw e;
} catch (RuntimeException ex) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per Effective Java don't catch a raw runtime exception, only the specific subclass you expect to be thrown

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

manage to change to } catch (ModelParserException e) {

as IOError is a sitting duck ready, for refactoring into void:

#2292 (comment)

It's not thrown, that's right. So do not add a throw clause.

@Pankraz76 Pankraz76 changed the title Modernize codebase with Java improvements - test DefaultModelProcessor#read Modernize codebase with Java improvements - test DefaultModelProcessor#read May 8, 2025
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor-test branch from 02b5deb to b6809cd Compare May 8, 2025 11:49
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor-test branch from b6809cd to 0b043ae Compare May 8, 2025 12:55
return parent.get().withPomFile(pomFile);
}
} catch (ModelParserException e) {
exceptions.add(e);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it mandatory to continue if an error occurs to give full error report? Or can we have here early exit if the branch kicks in like above in its counterpart?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose it depends on whether one parser throwing an exception invalidates answers from subsequent parsers in the loop. I suspect it doesn't since you skip subsequent parsers once one returns.

@Pankraz76 Pankraz76 requested a review from elharo May 8, 2025 13:00
Pankraz76 pushed a commit to Pankraz76/maven that referenced this pull request May 8, 2025
@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor-test branch from 0b043ae to 92b5e79 Compare May 8, 2025 13:03
return parent.get().withPomFile(pomFile);
}
} catch (ModelParserException e) {
exceptions.add(e);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose it depends on whether one parser throwing an exception invalidates answers from subsequent parsers in the loop. I suspect it doesn't since you skip subsequent parsers once one returns.

void readWithParserThrowingExceptionShouldCollectException() {
ModelXmlFactory factory = mock(ModelXmlFactory.class);
ModelParser parser = mock(ModelParser.class);
XmlReaderRequest request = mock(XmlReaderRequest.class);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this have to be mocked? can you just use the class?

when(mockSource.getPath()).thenReturn(Path.of("other/pom.xml"));
ModelParser parser = mock(ModelParser.class);
when(parser.locate(any())).thenReturn(Optional.of(mockSource));
assertTrue(assertThrows(IllegalArgumentException.class, () -> new DefaultModelProcessor(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nesting asserts is strange. Maybe don't do this, or split it into two separate statements

}

@Nested
class WithTmpFiles {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is strange. I haven't seen nested test classes before. Might be fine, but is there a strong reason for this?

Copy link
Contributor Author

@Pankraz76 Pankraz76 May 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SOC is kind of crazy at first, but it can be handy—and necessary for special test patterns. It simplifies complex scenarios without forcing to massively copy or abstract test code, as logic can now be shared and layered in one place.

It’s similar to a dedicated class but with inheritance, allowing special sub-conditions. That said, it’s flexible and therefore has significant trade-offs (both good and bad side effects).

JUnit Nested Classes: Quick Pros & Cons

Pros:
✅ Better organization
✅ Clearer test grouping
✅ Flexible setup per group
✅ Reduces duplication
✅ Good for stateful testing

Cons:
❌ Adds complexity
❌ IDE navigation may suffer
❌ Risk of over-nesting
❌ Must be non-static
❌ Learning curve for new devs

Best for: Complex tests with shared setups or multiple states.


@Test
void locateExistingPomWithDirectoryContainingPom() throws IOException {
testProjectDir = createTempDirectory(tempDir, "project");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test might belong elsewhere if it's not using the same fixture.


@Test
void locateExistingPomWithDirectoryWithoutPom() throws IOException {
testProjectDir = createTempDirectory(tempDir, "project");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test might belong elsewhere if it's not using the same fixture.


@Test
void locateExistingPomWithPomFile() throws IOException {
testPomFile = Files.createTempFile(tempDir, "pom", ".xml");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test might belong elsewhere if it's not using the same fixture.

} else {
return null;
}
private static Optional<Model> parent(XmlReaderRequest request, ModelParser parser, Path projectDirectory) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A parent usually refers to the parent model, so I'd rather use parentDirectory to make it clear what we're looking for.


private Model doRead(XmlReaderRequest request) throws IOException {
return modelXmlFactory.read(request);
private static void throwErrorsSuppressed(List<ModelParserException> exceptions) throws IOException {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're not using the IOException in the API, so not sure why we'd want to build one here. Model parsing exception aren't necessarily IoExceptions.

@Pankraz76 Pankraz76 force-pushed the functional-DefaultModelProcessor-test branch from 92b5e79 to 49d13d9 Compare May 9, 2025 10:17
.orElse(null))
.filter(Objects::nonNull)
.findFirst()
.orElseGet(() -> doLocateExistingPom(projectDirectory));
Copy link
Contributor Author

@Pankraz76 Pankraz76 May 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unpleasant do prefix is fix for naming collision @elharo

Copy link
Contributor Author

@Pankraz76 Pankraz76 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

finally covered, small polish.

.orElseGet(() -> locateExistingPomWithFallback(projectDirectory)));
}

private static Path throwIfWrongProjectDirLocation(Path projectDirectory, Path pom) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SOC

return pom;
}

private Path locateExistingPomWithFallback(Path project) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SRP


@Test
void locateExistingPomShouldHandleRegularFileInput() throws IOException {
// Create a temporary file
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

meldown

@Pankraz76 Pankraz76 changed the title Modernize codebase with Java improvements - test DefaultModelProcessor#read test cover DefaultModelProcessor#read May 9, 2025
@Pankraz76 Pankraz76 marked this pull request as draft May 10, 2025 23:03
@Pankraz76
Copy link
Contributor Author

wip reopen

@Pankraz76 Pankraz76 closed this May 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants