ppalaga commented on a change in pull request #2818:
URL: https://github.com/apache/camel-quarkus/pull/2818#discussion_r655527286
##########
File path: integration-test-groups/foundation/core/pom.xml
##########
@@ -43,13 +43,12 @@
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
</dependency>
-
- <!-- test dependencies -->
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-junit5</artifactId>
- <scope>test</scope>
</dependency>
Review comment:
I see that having junit in application class path simplifies the code a
bit by not having to pass complex objects over the wire, but I wonder whether
the pros outweight the cons: it is not only junit, it is quarkus-junit5 with
the whole set of its transitive deps, including quarkus-core-deployment, ASM,
jANSI and other funny stuff. Letting the native compiler to analyze them may
not only bring strange errors, but can also prolong the native compilation
(because it is more code). Having said that, I'd vote for not keeping junit in
test scope and using assertions in `src/test/java`. I know we have this pattern
in several other test modules, and I even may have approved it in the past.
Anyway, as long as there are better alternatives, we should consider preferring
them.
So what are the alternatives?
resteasy-jaxb/resteasy-jackson would solve the problem of passing complex
objects over the wire, but I think we should avoid even this one here in the
core test module, where we strive for a maximal methodological purity (read:
minimal dependency set).
What else?
How about adding an ad hoc `toString()` to
`PropertiesCustomBeanWithConstructorParameterInjection` and other beans and
returning it from the respective JAX-RS endpoint? I think it would serve the
purpose quite well. It would allow for both having minimal app dependencies and
moving the assertions to the test method. WDYT?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
