JiriOndrusek opened a new pull request, #3847: URL: https://github.com/apache/camel-quarkus/pull/3847
fixes https://github.com/apache/camel-quarkus/issues/3511 This is a draft with a simple POC to start a discussion about camel way of testing in camel-quarkus. I tried to add a functionality of `CamelTestSupport` into the camel-quarkus. I created our own annotation `CamelQuarkusTest`, which should be helpful for creating some Processors to enhance test functionality, but in this POC it is unused. I copied all tests from the [camel git repo](https://github.com/apache/camel/tree/camel-3.17.0/core/camel-core/src/test/java/org/apache/camel/processor/interceptor), which should cover bigger part of the required functionality. As you can see in the draft, each test has to be annotated with `@CamelQuarkusTest` and should extend `CamelQuarkusTestSupport`. There are a few limitations: * Quarkus runs all test within the smallest number of restarting quarkus engine (which means that quarkius starts before all tests and finishes after all the tests), therefore Camel context is created and started at the beginning of the lifecycle. Therefore tests has to be aware, that the context could be modified by the other tests (and reset mock endpoints for example or take care of it globally). To avoid this behavior, the simplest (but not performance wise) solution is to add annotation `@TestProfile`, which instructs Quarkus to restart the engine before running the test. * The fact that the camel context is already started, limits several usecases, which requires context restart (like debugger). * JUnit5 is not aware of quarkus's classloader and context, therefore all code (like junit5's callback after/before *) has to be rewritten into the Quarkus's [callbacks](https://quarkus.io/guides/getting-started-testing#enrichment-via-quarkustestcallback) (see for example `BeforeEachCallback`. added by this draft) * Properties override does not work, but it has to be investigated further whether this functionality should work in camel-quarkus (Test `UseOverridePropertiesWithPropertiesComponentTest`) * I enhanced a `Injectionpointsprocessor` to detect duplications of the synthetic beans, produced by tests. This code is just a "basic" POC to show theway of proper solution. (We can not register synthetic beans for each tests, becauseall of them are part of the context and there can be no duplicated beans. It is not possible to produce different beans with the same name) Some little changes has to be done also on camel side (to allow overriding of some test methods). For the POC, following changes are necessaery: https://github.com/apache/camel/compare/camel-3.17.0...JiriOndrusek:camel-quarkus-test-support WDYT? @ppalaga @jamesnetherton @zhfeng @aldettinger I thinng that this "feature" is quite complicated and should be discussed. In this POC I tried to show one possible way of resolving some problems. From my POV similar approach should work and should be helpful for users. In case we can add the full stop and start capabilty of the camel context, this would help this case a lot. Even without it, users should be able to use a big part of the functionality of camel test support. In case that tests are written safely, there might not be necessary to use `@TestProfile` and therefore avoid the performance issues. <!-- Uncomment and fill this section if your PR is not trivial [ ] An issue should be filed for the change unless this is a trivial change (fixing a typo or similar). One issue should ideally be fixed by not more than one commit and the other way round, each commit should fix just one issue, without pulling in other changes. [ ] Each commit in the pull request should have a meaningful and properly spelled subject line and body. Copying the title of the associated issue is typically enough. Please include the issue number in the commit message prefixed by #. [ ] The pull request description should explain what the pull request does, how, and why. If the info is available in the associated issue or some other external document, a link is enough. [ ] Phrases like Fix #<issueNumber> or Fixes #<issueNumber> will auto-close the named issue upon merging the pull request. Using them is typically a good idea. [ ] Please run mvn process-resources -Pformat (and amend the changes if necessary) before sending the pull request. [ ] Contributor guide is your good friend: https://camel.apache.org/camel-quarkus/latest/contributor-guide.html --> -- 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. To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
