[jira] [Updated] (CAMEL-20785) camel-test: CamelTestSupport is inadequatedly designed

["Otavio Rodolfo Piske (Jira)" <ji...@apache.org>]

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