On Mon, Jul 24, 2023 at 3:45 PM Nicolas Filotto <nfilo...@talend.com> wrote:
> > One problem, IMHO, camel-test-junit5 already has a dependency chain that > is > > pretty complex, which is one of the things I wanted to solve ... But, > more > > Sorry if it is a naive question but can't it be solved or at least > improved directly at camel-test-junit5 level? But please note this artifact > is relatively old (4 years) and the community doesn't seem to complain > about it so much so I guess it is not really seen as a big issue. > I am not sure if we can fix it easily. Right now we have something like this: camel-test-junit5 -> depends on core components -> depend on (some bits of) core -> core components are depended by core So, for any module that depends on camel-test-junit5, we have: module -> camel-test-junit5 -> depends on core components -> depend on (some bits of) core -> core components are depended by core I don't think it's the kind of problem our users would notice or complain about. I do think, however, that it makes it much harder for us as maintainers to understand the relationship between components and what each one of them brings. > > > importantly, the problem is that I think it would be detrimental to Camel > > and the community to have 2 test approaches (one based on the > > CamelTestSupport and another based on the JUnit 5 extension), even if the > > code is reorganized within camel-test-junit5. > > We already have 2 test approaches right now (even more if we count > test-main and test-spring), the only difference is that there are in > different artifacts. If your idea is to keep only one approach in the near > future, in both cases, it means that we will need to deprecate some classes > and then remove them. The only difference is that if we keep 2 artifacts, > the old artifact will need to be deprecated too, and then removed entirely. > Yeah, my medium term plan was to, eventually, have the JUnit extension to replace all of this. Of course, that would mean we could end up with some specialized artifacts (each on their respective sub-project) for Spring Boot and others (this is very speculative right now - just thinking freely about the future state if we ever would do this). > > As you have mentioned before the CI is not stable enough, so it would be > great if we could find a solution to make it more stable but I'm not really > convinced that rewriting all the existing tests will help, IMHO, it is more > a risk to add more flaky tests which would make the situation worse because > it is a huge change so it is easy to make mistakes while migrating. I > guess, I would be convinced if we could only migrate the unstable tests > first to prove that it really helps, and if so I would be more than happy > to give my +1 on it. > To be clear: the intention is not to rewrite "just to fix the CI". The proposed feature offered a different way to manage the CamelContext (one that would simplify and allow us to implement a range of new features). Stability would eventually come as a constant effort to convert and modernize the tests. Testing is far harder than what we tend to give credit for and all I was pointing out was that Camel - as great as it is - has a lot of technical debt in terms of testing. Also, some of the most stable tests we have are the ones that were converted already: camel-amqp, camel-kafka, camel-mongodb, camel-cassandra, camel-jms, camel-opensearch and camel-paho. Naturally, from time to time some of them do fail - as for instance the flakiness we are experiencing now with camel-jms - but given that it was fairly stable on the CI up to a few days ago, it's probably because something else disturbed them (I'm still investigating). > > As a recipient of an email from the Talend Group, your personal data will > be processed by our systems. Please see our Privacy Notice < > https://www.talend.com/privacy-policy/> for more information about our > collection and use of your personal information, our security practices, > and your data protection rights, including any rights you may have to > object to automated-decision making or profiling we use to analyze support > or marketing related communications. To manage or discontinue promotional > communications, use the communication preferences portal< > https://info.talend.com/emailpreferencesen.html>. To exercise your data > protection rights, use the privacy request form< > https://talend.my.onetrust.com/webform/ef906c5a-de41-4ea0-ba73-96c079cdd15a/b191c71d-f3cb-4a42-9815-0c3ca021704cl>. > Contact us here <https://www.talend.com/contact/> or by mail to either of > our co-headquarters: Talend, Inc.: 400 South El Camino Real, Ste 1400, San > Mateo, CA 94402; Talend SAS: 5/7 rue Salomon De Rothschild, 92150 Suresnes, > France > -- Otavio R. Piske http://orpiske.net
