Developing DevKit Connector Tests

ConnectorTestCase class inherits from org.mule.tck.junit4.FunctionalTestCase and wraps FunctionalTestCase methods in methods that facilitate automating connectors operations use cases and enforce a uniform approach on the construction of test suites. ConnectorTestCase is by <Connector>TestParent.java and this class becomes the parent test class for all of the test cases.

Provides methods for working with NullPayload, initialization of random test data and also date manipulation on the Spring file. Also enhances the exception message that’s displayed for more accurate debugging.

Extends the ConnectorTestCase class and might be used to override default framework configuration settings, add OAuth capabilities, implement helper methods, or store global settings for example to test run time out rules.

Common use cases of the service can be defined as this class methods in order to make them available to the rest of the test suite. This would make tests more readable and related to the specific domain of the connector.

All TestCases classes must extend from this TestParent.

Note: Do not run automation tests automatically by Maven as they require credentials.

Each operation on the connector has its <OperationName>TestCases.java class that contains its related test cases. The sequence of operations called along the @Before, @Test, @After cycle make an operation use case.

After building the connector, add target/generated-sources/mule to the project build path, it might be necessary to add additional generated sources to the build path depending on the connector (such as target/generated-sources/cxf).

Also, if the connector is Standard, remember to add a muleLicenseKey.lic to the src/test/resources folder and to remove it prior to committing your changes.

For each operation a maximum of two flows is placed on the automation-test-flows. One for mandatory attributes (this will test that no mandatory argument was left unimplemented on the connector) and if applicable another with all attributes (mandatory and optional, to build a more general case on the operation).

Change the connector version to current to avoid the configuration XML to get broken, e.g. from http://www.mulesoft.org/schema/mule/taleo/1.0-SNAPSHOT/mule-taleo.xsd to http://www.mulesoft.org/schema/mule/taleo/current/mule-taleo.xsd.

Connector credentials should be picked from the automation-credential.properties file during test development or if tests are to be run from within Eclipse. Populate the config element field with placeholders: configRefAttribute="${serviceName.configRefAttribute}"

For example:

Create a property placeholder that references automation-credentials.properties or add xmlns:context="http://www.springframework.org/schema/context" as an attribute of the Mule node as one of its child node:

Prior to committing, change the location value to the following to run the suites from the console or build plan by passing the URL where the automation-credentials.properties are stored:

AutomationSpringBeans stores the test data required for each test to run.

The most common case is to have a <testMethod>TestData map containing all the primitive values or bean references for a specific test. For more complex cases, additional beans for the test may be required besides the main "TestData" map.

The approach is that each test has its set of dedicated test values, hence the convention. Reusing the same bean on different test results in them being coupled; if some specific data setup is desired for a particular test, changes might end up producing an unexpected behavior on others.

By convention all bean IDs related to an operation should begin with the operation name followed by the bean class. This avoids name conflicts and make clear on which operation this bean is used.

Generate entity fields that contain unique values dynamically in order to make the automation runs more robust. For example:

Use the automation-credentials.properties files in conjunction with AutomationSpringBeans.xml to test user related operations.

Use a single flow and pass attributes values as null. No need to have two flows with different sets of attributes.

Base test cases names can be extended to cover particular cases, for example:

testMandatoryAttributes_UPDATEbatchType

Each class should declare a nullifyOptionalAttributes() method if applicable:

Call this method after initializing the TestRunMessage and prior to an operation under test invocation.

Most general case, generally applies filter to the responses test.

Use a #{null} expression to handle the different cases in the AutomationSpringBeans file.

Example:

If a message processor returns an object that can contain null field values, it is acceptable to perform an assertNotNull on the field followed by the functional assertion on the field. This avoids failures being logged as errors.

If a message processor has void as return type and the payload was not used to pass data to it you can use the org.mule.modules.tests.ConnectorTestUtils.assertNullPayload(Object) assertion.

Request test data and perform use case preparation logic on the @Before methods. @Test method should contain if possible only a single flow call (the one that relates to the operation under test) and the assertions on its payload. On the @After method the changes on the sandbox should be reverted.

The framework enforces:

Fixture and tearDown throw an exception so that unexpected errors on their logic or calls list as errors on the test and not as a failure.

If an exception is thrown on the @Test the test is listed as failed:

One for each test case type (SmokeTest, RegressionTest). Place in the the org.mule.modules.<connector>.automation.

For now, inbound endpoint testing must be done by adding a VM endpoint in the flow that has the inbound endpoint we want to test. A VM endpoint is essentially an in-memory queue (hence the name VM, because they are handled by the JVM) addressable by URL that stores messages until they are processed. By storing the messages received by the inbound endpoint in a VM queue, we can retrieve them in the test case and make assertions on them.

For example, if we wanted to test SQS’s Receive Messages operation, we would need two flows: a flow that actually sends the message, and another flow with the Receive Messages inbound endpoint, as such:

To actually get the messages to use in our test, add a VM endpoint to the flow:

To use the VM endpoint, add it as a Maven dependency to your project:

Also, update XML schemas and namespaces. See the VM endpoint documentation for details.

In your test case, use the runFlowAndWaitForResponseVM method. The important thing to note here is the path of the queue. A simple test for these flows is:

The parameters for runFlowAndWaitForResponseVM are as follows:

This information can also be seen in the Javadoc for this method.

This is a preliminary way to implement this functionality because ideally there should be no need to manually add endpoints to flows in order to test them.

The accessToken has to be manually generated and then passed along with the credentials to the service in order to run the test suite.

Let’s use Facebook as example:

Either in the <ConnectorName>TestParent:

Or if using Eclipse in Preferences > Java > Installed JREs, edit the JRE and add -Dmule.test.timeoutSecs=300 to the default VM arguments.

Place the following files into /<connector-project>/src/test/resources_:_