TestMixIns

The TestMixIn feature allows you to selectively enable additional test functionality based on the capabilities of your application. To include MixIn support in your application, you must include a Maven dependency in your application's pom.xml.

<dependency>
    <groupId>org.switchyard.components</groupId>
    <artifactId>switchyard-component-test-mixin-name</artifactId>
    <version>release-version</version> <!-- e.g. "0.7.0" -->
    <scope>test</scope>
</dependency>

• CDIMixIn (switchyard-component-test-mixin-cdi) : boostraps a stand-alone CDI environment, automatically discovers CDI beans, registers bean services, and injects references to SwitchYard services.

• HTTPMixIn (switchyard-component-test-mixin-http) : client methods for testing HTTP-based services.

• SmooksMixIn (switchyard-component-test-mixin-smooks) : stand-alone testing of any Smoooks transformers in your application.

• BPMMixIn (switchyard-component-test-mixin-bpm) : utility methods for working with jBPM 5 Human Tasks (like starting/stopping a TaskServer).

• HornetQMixIn (switchyard-component-test-mixin-hornetq) : bootstraps a stand-alone HornetQ server and provides utility methods to interact with it for testing purpose. It can be also used to interact with remote HornetQ server.

• NamingMixIn (switchyard-component-test-mixin-naming) : provides access to naming and JNDI services within an application.

• PropertyMixIn (switchyard-test) : provides ability to set test values to properties that are used within the configuration of the application.

Scanners

Scanners add classpath scanning as part of the test lifecycle. This adds the same Scanner behavior as is available with the SwitchYard maven build plugin, but allows the scanning to take place as part of the test lifecycle. The following Scanners are available:

• BeanSwitchYardScanner: Scans for CDI Bean Service implementations.

• TransformSwitchYardScanner: Scans for Transformers.

• BpmSwitchYardScanner: Scans for @Process, @StartProcess, @SignalEvent and @AbortProcessInstance annotations.

• RouteScanner: Scans for Camel Routes.

• RulesSwitchYardScanner: Scans for @Rule annotations.

Deployment Injection

The Deployment instance can be injected by declaring a property of type Deployment.

@RunWith(SwitchYardRunner.class)
public class MyServiceTest  {

    private Deployment deployment;

    // implement test methods...
}

SwitchYardModel Injection

The SwitchYardModel instance can be injected by declaring a property of type SwitchYardModel.

@RunWith(SwitchYardRunner.class)
public class MyServiceTest  {

    private SwitchYardModel model;

    // implement test methods...
}

ServiceDomain Injection

The ServiceDomain instance can be injected by declaring a property of type ServiceDomain.

@RunWith(SwitchYardRunner.class)
public class MyServiceTest  {

    private ServiceDomain serviceDomain;

    // implement test methods...
}

TransformerRegistry Injection

The TransformerRegistry instance can be injected by declaring a property of type TransformerRegistry.

@RunWith(SwitchYardRunner.class)
public class MyServiceTest  {

    private TransformerRegistry transformRegistry;

    // implement test methods...
}

TestMixIn Injection

TestMixIn instance(s) can be injected by declaring properties of the specific type TestMixIn type.

@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(mixins = {CDIMixIn.class, HTTPMixIn.class})
public class MyServiceTest  {

    private CDIMixIn cdiMixIn;
    private HTTPMixIn httpIn;

    // implement test methods...
}

PropertyMixIn Injection

PropertyMixIn instance(s) are injected like any other TestMixIn type, however any properties you set on the mix in have to be done before deployment to be respected, thus the use of the @BeforeDeploy annotation:

@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(mixins = {CDIMixIn.class, PropertyMixIn.class, HTTPMixIn.class})
public class MyServiceTest  {

    private PropertyMixIn propMixIn;
    private HTTPMixIn httpMixIn;

    @BeforeDeploy
    public void setTestProperties() {
        propMixIn.set("soapPort", Integer.valueOf(18002));
    }

    // implement test methods...
}

Invoker Injection

Service Invoker instance(s) can be injected by declaring properties of type Invoker and annotating them with @ServiceOperation annotation.

@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(config = "testconfigs/switchyard-01.xml")
public class MyServiceTest  {

    @ServiceOperation("OrderService.createOrder")
    private Invoker createOrderInvoker;

    @Test   
    public void test_createOrder() {
        createOrderInvoker.sendInOnly("<order><product>AAA</product><quantity>2</quantity></order>");
    }
}

Note the annotation value is a dot-delimited Service Operation name of the form "service-name.operation-name".

Selectively Enabling Activators for a Test

The test framework defaults to a mode where the entire application descriptor is processed during a test run.  This means all gateway bindings and service implementations are activated during each test.  There are times when this may not be appropriate, so we allow activators to be selectively enabled or disabled based on your test configuration.

The following example excludes SOAP bindings from all tests.  This means that SOAP gateway bindings will not be activated when the test framework loads the application.

@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(config = "testconfigs/switchyard-01.xml" exclude="soap")
public class NoSOAPTest  {
   ...
}

This example includes only CDI bean services defined in the application descriptor.

@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(config = "testconfigs/switchyard-02.xml" include="bean")
public class BeanServicesOnlyTest  {
...
}

Preparing procedure for the Test

Sometimes we need to add some procedures before test is performed. JUnit @Before operation is invoked right after the application is deployed, however, it can't be used if you expect something before deploy. We have @BeforeDeploy annotation for this purpose. This is required to test the application which has JCA binding with using JCAMixIn since the ResourceAdapter must be deployed before the application is activated.

This is the example for deploying HornetQ ResourceAdapter to the embedded IronJacamar JCA Container using JCAMixIn.

@BeforeDeploy
public void before() {
    ResourceAdapterConfig ra = new ResourceAdapterConfig(ResourceAdapterConfig.ResourceAdapterType.HORNETQ);
    _jcaMixIn.deployResourceAdapters(ra);
}