Otavio Rodolfo Piske created CAMEL-20838:
--------------------------------------------

             Summary: camel-test: block usages of internal APIs.
                 Key: CAMEL-20838
                 URL: https://issues.apache.org/jira/browse/CAMEL-20838
             Project: Camel
          Issue Type: Task
          Components: camel-test
    Affects Versions: 4.7.0
            Reporter: Otavio Rodolfo Piske
            Assignee: Otavio Rodolfo Piske
             Fix For: 4.x


Over the course of years, multiple additions and changes to the 
CamelTestSupport class have made it extremely fragile, tightly coupled and hard 
to maintain.

Among the problems of this class:
 * Mixing up being responsibilities
 ** It is both a JUnit 5 extension and *also* a base test class
 *** Which leads to multiple ways to setup and tear down the test (either via 
extension methods or via setup/tearDown methods + the setup/tearDown from the 
tests itself)
 ** In addition to being also a JUnit 5 extension and a base test class ... it 
is ALSO a BreakPoint.
 ** And a utility class that provides helper methods (i.e.: providing utility 
methods for useful operations - send/receive requests)
 ** And also a test configuration class in itself (i.e.: allowing tests to 
configure themselves by overriding methods)
 * Over-complexity
 ** the code tries to handle different lifecycle supported by JUnit 
 ** along with concurrency
 ** as well as setting up and managing the CamelContext
 * Mix up assertions with assumptions
 * Little control about the initialization order of the extension (itself ?) 
via JUnit's Order annotation
 * Three ways to manage JMX: useJMX, enableJMX, disableJMX.

 

To make things even worse, the wide open interfaces provided by this [class 
have leaked to other 
projects|https://github.com/apache/camel-quarkus/blob/main/test-framework/junit5/src/main/java/org/apache/camel/quarkus/test/CamelQuarkusTestSupport.java]
 (such as Camel Quarkus).

 

The work on this ticket is related to transforming the ContextLifecycleManagers 
into full-blown JUnit extensions. As this is a breaking change in a few 
aspects, this work is planned for 4.9.0 (or whatever is the next release after 
the next LTS).

 

 

 

 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to