[ 
https://issues.apache.org/jira/browse/CAMEL-20785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Otavio Rodolfo Piske updated CAMEL-20785:
-----------------------------------------
    Description: 
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

 

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).

 

 

 

 

  was:
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
 ** And also a test configuration class in itself
 * Overcomplexity
 ** 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

 

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).

 

 

 

 


> camel-test: CamelTestSupport is inadequatedly designed
> ------------------------------------------------------
>
>                 Key: CAMEL-20785
>                 URL: https://issues.apache.org/jira/browse/CAMEL-20785
>             Project: Camel
>          Issue Type: Task
>            Reporter: Otavio Rodolfo Piske
>            Assignee: Otavio Rodolfo Piske
>            Priority: Major
>
> 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
>  
> 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).
>  
>  
>  
>  



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

Reply via email to