Mule ctf
3 likes1,036 views
The Connector Testing Framework (CTF) enables the creation of connector functional tests in a way that decouples how Mule works and how tests are written. It provides interfaces to initialize and run tests in either embedded or remote Mule instances, allowing tests to be run on multiple Mule versions. The framework includes interfaces for the connector test context and connector dispatcher, which are used to execute connector operations and paginated, DataSense, and WSDL tests. CTF configuration options include credentials properties files and framework properties that can be set via Maven or system properties.
![CTF Interfaces
2. ConnectorDispatcher<T>: An interface enabling the execution of connector
operations, including paginated, DataSense and WSDL operations. It contains the
following methods:
1. createMockup(): Returns an instance of the connector being tested, which is the
same class type as used as the only argument in the initialisation of the framework
through ConnectorTestContext.initialize(connectorClass). Tests operations are
executed through this instance, except for operations annotated with @Paged.
2. runPaginatedMethod(String methodName, Object[] args): Connector operations
annotated with @Paged are executed through this method, which requires the
operation name (camel-like) and the array of arguments for that specific
operation.
3. fetchMetaDataKeys(): Returns a Result (from org.mule.commons package) containing
a list of MetaDataKeys (from org.mule.common.metadata package) in order to test
MetaData.
4. fetchMetaData(MetaDataKey key): Returns a MetaData object
(from org.mule.common.metadata package) for a particular MetaDataKey
(from org.mule.common.metadata package).
5. invokeWSDLOperation(XMLStreamReader input, String WSDLID, String operationName):
Dispatcher operation to test WSDL operations.
5](https://image.slidesharecdn.com/mulectf-170516125232/85/Mule-ctf-5-320.jpg)
Mule ctf
- 1. MULE –Connector Testing Framework - CTF -RajeshKumar 1
- 2. Connector Testing Framework - CTF The Connector Testing Framework eases the creation of connector functional tests, where the developer is not necessarily involved with Mule’s internals, such as flows, configurations and Spring beans. The objective of this framework is twofold. On the one hand, we decouple how Mule works and how functional tests are written. On the other hand, we enable a runtime platform to run connector functional tests with multiple Mule versions by executing the tests in remote Mule instances, achieving a decoupled runtime environment. 2
- 3. Overview of CTF This framework is the default testing framework to write connector functional tests. It has evolved from a previous testing framework, where the notion of Mule flows and Spring beans were used. We now have a simple and well-defined interface to run functional tests in different ways: Embedded or Remote. The overall approach is to decouple the test itself from where it is executed, thus enabling a developer to determine whether a test runs in different Mule execution environments. For instance, a connector written for Mule 3.5.x can now be automatically tested in Mule releases 3.x and determine backward-compatibility and forward-compatibility issues, as well as class-loading problems. 3
- 4. CTF Interfaces 1. ConnectorTestContext<T>: Main class of the framework, providing an interface for the other important class, the ConnectorDispatcher. It contains the following methods: a) initialize(Class<T> connectorClass): A class method to initialise the entire framework. It requires the class of the connector under test. b) shutDown(): A class method to shut down the entire framework. c) getInstance(): A class method that returns the only instance of the connector context prior to initialisation. Otherwise, it will throw and exception if the framework has not been initialised. d) getPlatformManager(): Returns the only instance of the platform manager in charge of dealing with the framework life cycle. e) getConnectorDispatcher(): Returns the only instance of the connector dispatcher, which is in charge of executing the connector operations. 4
- 5. CTF Interfaces 2. ConnectorDispatcher<T>: An interface enabling the execution of connector operations, including paginated, DataSense and WSDL operations. It contains the following methods: 1. createMockup(): Returns an instance of the connector being tested, which is the same class type as used as the only argument in the initialisation of the framework through ConnectorTestContext.initialize(connectorClass). Tests operations are executed through this instance, except for operations annotated with @Paged. 2. runPaginatedMethod(String methodName, Object[] args): Connector operations annotated with @Paged are executed through this method, which requires the operation name (camel-like) and the array of arguments for that specific operation. 3. fetchMetaDataKeys(): Returns a Result (from org.mule.commons package) containing a list of MetaDataKeys (from org.mule.common.metadata package) in order to test MetaData. 4. fetchMetaData(MetaDataKey key): Returns a MetaData object (from org.mule.common.metadata package) for a particular MetaDataKey (from org.mule.common.metadata package). 5. invokeWSDLOperation(XMLStreamReader input, String WSDLID, String operationName): Dispatcher operation to test WSDL operations. 5
- 6. Framework Configuration Maven Dependencies CTF is packed within DevKit 3.7+ and therefore no dependency is further required. Properties We can inject framework properties through Maven options or VM arguments (in Eclipse, for instance). If no configurable parameters are desired, you can just add these properties with System.setProperty(key,value) within your code. The following CTF parameters are configurable: 6
- 7. Framework Configuration Automations Credentials Properties File: Optional. This file includes the required credentials to run a test suite and it is specified as -Dautomation- credentials.properties=FILENAME. If no option is given and no file named automation- credentials.properties exists, a default file will be created within src/test/resources and an exception will be thrown. If a file already exists with this name, it will be used by default and a warning will be issued. It is mandatory to specified the file as follows: configName1.configurationAttribute1=value configName1.configurationAttribute2=value ... configName2.configurationAttribute1=value configName2.configurationAttribute2=value ... 7
- 8. Installing CTF locally The framework can be locally installed by cloning its repository and running mvn clean install. Integration tests will not work out of the box, since they required the same configuration as previously detailed. You will need to include the following Maven options if integration tests are ran: mvn clean install -Dtest=FullTestSuite -DfailIfNoTests=false -Dmuledirectory=<Mule directory> 8
- 9. THANK YOU 9
- 10. THANK YOU 9