Details
-
Task
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
Moderate
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)
- It is both a JUnit 5 extension and also a base test class
- 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 (such as Camel Quarkus).
Attachments
Issue Links
- is blocked by
-
CAMEL-20893 camel-jms: simplify JmsRouteRequestReplyTest
- Resolved
- is cloned by
-
CAMEL-20837 camel-test: implement extensions for CamelTestSupport
- Resolved
- relates to
-
CAMEL-21078 camel-test-junit5: enabling adviceWith should be available for consumer code.
- Resolved
-
CAMEL-21080 camel-test: create legacy interfaces
- Open
-
CAMEL-20838 camel-test: block usages of internal APIs.
- Resolved
- links to