ppalaga commented on pull request #2739: URL: https://github.com/apache/camel-quarkus/pull/2739#issuecomment-857139522
The same kind of questions like @aldettinger asked came to my mind. > > ``` > > 3. When testing scenarios involving globalOptions(), would it be better to have a new CamelContext for each subset of global options ? Maybe another itest project or something like a quarkus test profile ? > > ``` > > > Definitely you are correct, a new camelcontext for each testcase should be more isolated and clear. but I don't know how to do it easily in camel-quarkus test framework. So feel free to shed light or even point me an existing example. Yeah, having a separate itest module for each of the tested converter setups would probably be an overkill (although we have a couple of itest modules for e.g. camel-main). I wonder whether this is not a use case for a `io.quarkus.test.QuarkusUnitTest`. We have such tests e.g. in [Servlet extension](https://github.com/apache/camel-quarkus/tree/main/extensions/servlet/deployment/src/test/java/org/apache/camel/quarkus/component/servlet/test). A big advantage of those is that they are very lightweight and fast. You can have a special context setup per test class. But OTOH, they are executed only in JVM mode. So we maybe need to find a way how to keep a part of the scenario in a proper itest and move the rest to QuarkusUnitTest-style test. I'd say if the second setup with `context.getGlobalOptions().put(JacksonConstants.TYPE_CONVERTER_MODULE_CLASS_NAMES, JaxbAnnotationModule.class.getName());` uncovered the need for the reflection registration, then that setup should stay ghere and be hardwired for the whole itest module. The first setup (without TYPE_CONVERTER_MODULE_CLASS_NAMES) could then be transformed to a separate `io.quarkus.test.QuarkusUnitTest`. In that way we'd both have clean and readable tests without needing to configure the context in the middle of the flight and we still cover what we need in native mode. 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
