Hi Sorry at this time I cannot support these kinds of changes.
We have a standard practice in Camel on how to do unit tests (camel-test) which we had for 15+ years. We should dog food our own standard, and it's also a way for end users to see existing src/test code, how to use a given Camel component, and also how they can write tests. If I compare the Camel standard today vs test-infra in a PR like this https://github.com/apache/camel/pull/10739/files Then that "new code" is worse and more hard to write, understand and do for end users. For advanced situations with test-containers / docker / embedded some database (or other systems) then I agree its good to have some "test-infra" that can more easily setup this. Which was my understanding of the need for test-infra in the first place. But for plain tests then camel-test should be used. Also we should not change all this code in components "just because" as we also need to backport fixes to 3.x branches and its always a pain when there have been too many changes (yes it's a bit ironic coming from me, who does many changes on the main branch for the v4 work). That just risks us not doing backports because it was too painful and time consuming. In terms of Quarkus testing, then mind that camel-core is an Apache project and not Quarkus. Such things are potentially better done in the camel-quarkus project itself. In terms of improving camel-test to for example not need to extend a base class, then all of that work was started as part of camel-test-spring (such as: https://github.com/apache/camel/blob/main/components/camel-test/camel-test-spring-junit5/src/main/java/org/apache/camel/test/spring/junit5/MockEndpoints.java ) There is an old JIRA to improve and add more features, and today those annotation based configuration could IMHO be moved out of camel-test-spring into the general camel-test, to make it more generic. https://issues.apache.org/jira/browse/CAMEL-6070 Over the years some people have stepped up to help with this, but it was bigger work than they anticipated, so we didn't finish all the work. And what we have already covers a decent size of use-cases. On Thu, Jul 20, 2023 at 8:38 AM Otavio Rodolfo Piske <angusyo...@gmail.com> wrote: > Hi Claus, > > test infra solves a few problems that we have in camel-test-support-junit5: > - it has a simpler dependency chain (it depends only on core) > - it allows managing the service ordering explicitly (i.e.: it's possible > to define in which order services can be initialized) > - it is much simpler and the JUnit 5 extension model gives us more > flexibility for additional features in the future (more on that later) > - it's not tightly coupled to one specific type of context or it's > lifecycle (i.e.: consider for instance how we have to set isUseRouteBuilder > to skip adding route builders on CamelTestSupport based tests) > > So, for instance, instead of tightly coupling a test to CamelTestSupport by > extending it ... we can just use JUnit's 5 extension model to add a context > to the test: > > @RegisterExtensionpublic static CamelContextExtension > camelContextExtension = new DefaultCamelContextExtension(); > > > (+ the required setup of routes and context configuration - which is > required CamelTestSupport as well). > > Ultimately my hope is that we can harden this enough so that we can start > publicizing this to the end users and envolve it to support other features > (like Quarkus Continuous Testing - which, IMHO, would require a lot more > coordination with the service and context lifecycle than what we can do > with CamelTestSupport). > > What do you think? > > Kind regards > > > On Thu, Jul 20, 2023 at 7:24 AM Claus Ibsen <claus.ib...@gmail.com> wrote: > > > Hi > > > > I noticed that we are migrating some components to use camel-test-infra > for > > unit testing. > > And I think it makes sense when you have > > > > - need to use docker / test-containers > > - or to setup some internal embedded system that usually would require a > > base class with some code to do that. > > > > However for basic components that are not in need for that then we should > > not use camel-test-infra but just regular camel-test, just as camel end > > users will do that. > > > > For example this PR > > https://github.com/apache/camel/pull/10739 > > > > I fail to see the need for test-infra-core for camel-asn1. This is just a > > message transformation (dataformat) library that works purely in-memory. > > > > > > > > -- > > Claus Ibsen > > ----------------- > > @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > > > > > -- > Otavio R. Piske > http://orpiske.net > -- Claus Ibsen ----------------- @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
