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
