Chapter 14. Testing Support in SwitchYard

SwitchYard uses JUnit, which is a unit testing framework for Java. SwitchYard provides comprehensive unit test support for testing your applications. There are three primary elements to test support in SwitchYard:
  • SwitchYardRunner
  • SwitchYardTestKit
  • SwitchYardTestCaseConfig

14.1. SwitchYardRunner Class

The SwitchYardRunner Class is a JUnit test Runner class that takes care of bootstrapping an embedded SwitchYard runtime and deploying a SwitchYard application for the test instance.
In order to take advantage of the test support in SwitchYard, ensure that your unit test is annotated with the SwitchYardRunner JUnit test Runner class. The SwitchYardRunner creates and starts an embedded runtime for each test method. After the embedded runtime starts, the project containing the test is packaged as a SwitchYard application and deployed to it. An instance of the SwitchYardTestKit class is injected into the test when a property of type SwitchYardTestKit is declared in the test. This instance represents the runtime state of the deployed SwitchYard test application.
@RunWith(SwitchYardRunner.class)
public class MyServiceTest  {
 
    private SwitchYardTestKit testKit;
 
    @Test   
    public void testOperation() {
        MyTestServiceHandler service = new MyTestServiceHandler();
 
        // register the service...
        testKit.registerInOutService("MyService", service);
       
        // invoke the service and capture the response...
        Message response = newInvoker("MyService")
        .sendInOut("<create>A1234</create>");
 
        // test the response content by doing an XML comparison with a
        // file resource on the classpath...
        testKit.compareXMLToResource(response.getContent(String.class), "/myservice/expected-create-response.xml");
    }
 
    private class MyTestServiceHandler implements ExchangeHandler {
        // implement methods....
    }
}
The SwitchYardTestKit class provides a set of utility methods for performing all sorts of deployment configuration and test operations.

14.2. SwitchYardTestKit Class

The SwitchYardRunner Class represents the runtime state of the deployed SwitchYard application instance deployed by SwitchYardRunner. It also provides access to a set of test utility methods for the test (For example, assertion methods). If a property of type SwitchYardTestKit is declared in the test, the SwitchYardTestKit is injected into the test instance.

14.3. SwitchYardTestCaseConfig

The SwitchYardTestCaseConfig annotation is optional. You can use it control the behavior of the SwitchYardRunner:
  • config: Enables you to specify a SwitchYard XML configuration file (switchyard.xml) for the test. The SwitchYardRunner attempts to load the specified configuration from the classpath. If it fails to locate the config on the classpath, it attempts to locate it on the file system (For example, within the project structure).
  • mixins: Enables you to add specific testing tools to your test case. Each TestMixIn is a composition-based method that provides customized testing tools for service implementations, gateway bindings, and transformers. When a TestMixIn is annotated on a test class, the SwitchYardRunner handles all the initialization and cleanup (life cycle) of the TestMixIn instances. It is also possible to manually create and manage TestMixIn instances within your test class if you are not using the SwitchYardRunner.
  • scanners: Enables you to add classpath scanning as part of the test life cycle. This adds the same Scanner behavior as the one available with the SwitchYard maven build plug-in. However, it allows the scanning to take place as part of the test life cycle. You may need to add Scanners if you want your test to run inside your IDE. This is because running your test inside your IDE bypasses the whole maven build process, which means the build plug-in does not perform any scanning.
Here is how you can use the SwitchYardTestCaseConfig annotation:
@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(config = "testconfigs/switchyard-01.xml", mixins = {CDIMixIn.class}, scanners = {BeanSwitchYardScanner.class, TransformSwitchYardScanner.class})
public class MyServiceTest  {
 
    @Test   
    public void testOperation() {
        newInvoker("OrderService")
        .operation("createOrder")
        .sendInOnly("<order><product>AAA</product><quantity>2</quantity></order>");
    }
}

14.4. Add Test Support to a SwitchYard Application

You can add test support to your SwitchYard application by adding a dependency to the switchyard-test module in your application's pom.xml as shown below:
<dependency>
    <groupId>org.switchyard</groupId>
    <artifactId>switchyard-test</artifactId>
    <version>[release-version]</version> <!-- e.g. "1.1.1-p5-redhat-1" -->
    <scope>test</scope>
</dependency>

Note

Note: camel dependency version is 2.10.0.redhat-60024.
In addition to a dependency on the core test framework, you can also use the MixIns in your test classes.

14.5. The TestMixIn Feature

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. "1.0" -->
    <scope>test</scope>
</dependency>

14.6. TestMixIn Classes

  • 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.
  • 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.

14.7. Scanners

Scanners add classpath scanning as part of the test life cycle. This adds the same Scanner behavior as is available with the SwitchYard maven build plug-in, but allows the scanning to take place as part of the test life cycle. SwitchYard provides the following Scanners:
  • BeanSwitchYardScanner: Scans for CDI Bean Service implementations.
  • TransformSwitchYardScanner: Scans for Transformer
  • BpmSwitchYardScanner: Scans for @Process, @StartProcess, @SignalEvent and @AbortProcessInstance annotations.
  • RouteScanner: Scans for Camel Routes
  • RulesSwitchYardScanner: Scans for @Rule annotations

14.8. Metadata and Support Class Injections

14.8.1. TestKit Injection

  • You can inject the SwitchYardTestKit instance into the test at runtime by declaring a property of that type in the test class, as shown below:
    @RunWith(SwitchYardRunner.class)
    public class MyServiceTest  {
     
        private SwitchYardTestKit testKit;
     
        // implement test methods...
    }				
    

14.8.2. Deployment Injection

You can inject the deployment instance by declaring a property of the type Deployment, as shown below:
  
@RunWith(SwitchYardRunner.class)
public class MyServiceTest  {
 
    private Deployment deployment;
 
    // implement test methods...
}

14.8.3. SwitchYardModel Injection

You can inject the SwitchYardModel instance by declaring a property of the type SwitchYardModel, as shown below:
 
@RunWith(SwitchYardRunner.class)
public class MyServiceTest  {
 
    private SwitchYardModel model;
 
    // implement test methods...
}

14.8.4. ServiceDomain Injection

You can inject the ServiceDomain instance by declaring a property of the type ServiceDomain, as shown below:
 
@RunWith(SwitchYardRunner.class)
public class MyServiceTest  {
 
    private ServiceDomain serviceDomain;
 
    // implement test methods...
}

14.8.5. TransformerRegistry Injection

You can inject the TransformerRegistry instance by declaring a property of the type TransformerRegistry, as shown below:
  
@RunWith(SwitchYardRunner.class)
public class MyServiceTest  {
 
    private TransformerRegistry transformRegistry;
 
    // implement test methods...
}

14.8.6. TestMixIn Injection

You can inject the TestMixIn Injection instance by declaring a property of the type TestMixIn Injection, as shown below:
@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(mixins = {CDIMixIn.class, HTTPMixIn.class})
public class MyServiceTest  {
 
    private CDIMixIn cdiMixIn;
    private HTTPMixIn httpIn;
 
    // implement test methods...
}			

14.8.7. PropertyMixIn Injection

PropertyMixIn instances are injected like any other TestMixIn type, however you must set any properties you wish to use on the MixIn before deployment in order for them to be used. To do this, use 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...
}

14.8.8. Invoker Injection

To inject Service Invoker instances, declare properties of the type Invoker and annotate them with @ServiceOperation. (Note the annotation value is a dot-delimited Service Operation name of the form [service-name].[operation-name].)
  
@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>");
    }
}

14.9. 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.
In this example, SOAP bindings are excluded 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 as defined in the application descriptor:
@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(config = "testconfigs/switchyard-02.xml" include="bean")
public class BeanServicesOnlyTest  {
...
}
Sometimes you will need to add some procedures before you perform the test. The JUnit @Before operation is invoked immediately after the application is deployed. You cannot, however, use it if you expect something to happen before deployment.

14.10. Useful Tips for Creating JUnit Tests

14.10.1. Invoking a Component Service

In order to invoke a component service, you must inject an invoker for certain ServiceOperation. When injecting a service operation, specify it in [service_name].[operation_name] notation.
import org.switchyard.test.Invoker;
...

@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(mixins = CDIMixIn.class)
public class ExampleServiceTest {

    @ServiceOperation("ExampleService.submitOperation")
    private Invoker submitOperation;

    @Test
    public void testOK() throws Exception {
        ParamIn testParam = new ParamIn()
            .set...(...);

        ParamOut result = submitOperation
            .sendInOut(testParam)
            .getContent(ParamOut.class);

        Assert....
    }

    @Test
    public void testForFault() throws Exception {
        ParamIn testParam = new ParamIn()
            .set...(...);

        try{
            // This method invocation should throw a fault
            ParamOut result = submitOperation
                .sendInOut(testParam)
                .getContent(ParamOut.class);

            Assert.fail
        } catch (InvocationFaultException ifex){
            Assert.... // Assert for correct type of exception
        }
    }
An invocation to a service operation can throw a InvocationFaultException whenever the method throws a fault. So catching this exception is similar to validating for the fault being thrown.
You can:
  • Check against original exception by checking the type of the InvocationFaultException:
     ifex.isType(MyOriginalException.class)
  • Use the JUnit functionality of setting the expected exception in the test:
     @Test(expected=org.switchyard.test.InvocationFaultException.class)

14.10.2. SwitchYardTestKit Utility Methods

TestKit provides the following set of utility methods to ease validations and some common operations that are performed on test classes:
  • Access to underlying
    • getTestInstance
    • getActivators
    • getDeployment
    • getServiceDomain
    • createQName
  • Service manipulation
    • registerInOutService
    • registerInOnlyService
    • removeService
    • replaceService
  • Invocation
    • newInvoker
  • Transformations
    • addTransformer
    • newTransformer
    • registerTransformer
  • MixIns
    • getMixIns
    • getMixIn
  • Dependencies
    • getRequiredDependencies
    • getOptionalDependencies
  • Resources
    • getResourceAsStream
    • readResourceBytes
    • readResourceString: Reads a resource (file) form the classpath
    • readResourceDocument
  • Configuration
    • loadSwitchYardModel
    • loadConfigModel
  • XML Comparison
    • compareXMLToResource: Compares a XML in string format with a XML file in the classpath.
    • compareXMLToString
  • Tracing
    • traceMessages: enables message tracing for the application under test.

14.10.3. Testing Transformations in Component Service

While testing a component invocation, you can test for the appropriate transformation with additional methods on the invocation. You can do this for the input transformation, as well as for the output transformation as shown below:
...

    @ServiceOperation("ExampleService.submitOperation")
    private Invoker serviceOperationInvocation;

    @Test
    public void testForInputTransformation() throws Exception {
        ParamOut result =  serviceOperationInvocation
                           .inputType(QName.valueOf("{urn:com.examaple:service:1.0"}submitOperation))
                           .sendInOut(....)
                           .getContent(ParamOut.class);
        Assert....  // Assert that result is OK, so transformation was OK
    }

    @Test
    public void testForOutputXMLTransformation() throws Exception {
        ParamIn testParam = new ParamIn()
            .set...(...);

        ParamOut result =  serviceOperationInvocation
                           .expectedOutputType(QName.valueOf("{urn:com.examaple:service:1.0"}submitOperationResponse))
                           .sendInOut(testParam)
                           .getContent(Element.class); // Expect Element as transformation is for XML

        XMLAssert....  // Assert that result is what is expected
    }
You can use XMLUnit and XMLAssert from org.custommonkey.xmlunit to ease validations.

14.10.4. Mocking a Service, Component, or Reference

Mocking a component may be useful, so it is never invoked for the sake of a test. For this, SwitchYardTestKit provides with the ability of adding, replacing, or removing services.
 // replace existing implementation for testing purposes
    testKit.removeService("MyService");s
    final MockHandler myService = testKit.registerInOnlyService("MyService");

    .... // Invoke the service under test

    // Assert what has arrived ath the mocked service
    final LinkedBlockingQueue<Exchange> recievedMessages = myService.getMessages();
    assertThat(recievedMessages, is(notNullValue()));

    final Exchange recievedExchange = recievedMessages.iterator().next();
    assertThat(recievedExchange.getMessage().getContent(String.class), is(equalTo(...)));
  • If you want to assert what has arrived or produced in the MockHandler, you can use the following options:
    • getMessages(): This provides with the list of received messages.
    • getFaults(): This provides with the list of prodced faults.
  • If the service is InOut, you may need to mock a response. You can use the following options:
    • forwardInToOut()
    • forwardInToFault()
    • replyWithOut(Object)
    • replyWithFault(Object)
      For example:
      final MockHandler mockHandler = testKit.registerInOutService("MyService");
          mockHandler.forwardInToOut();
  • If you want to instruct the MockHandler to wait for certain message, you can use the following options:
    • waitForOkMessage()
    • waitForFaultMessage()
      The MockHandler waits for 5 seconds by default, unless instructed to wait for a different period with setWaitTimeout(milis).

14.10.5. Mocking a Service For More Than One Method Invocation

In some cases, the service you are mocking may be called
  • Twice in the context of a single unit test, or
  • Multiple times for the same method, or
  • Multiple times for different methods
In this case, you can register an ExchangeHandler with the mock, while registering and replacing the original service. The ExchangeHandler gets the message, and contains the logic that you need to put to deal with this scenario, as shown below:
 testKit.replaceService(qname, new ExchangeHandler() {

        @Override
        public void handleMessage(Exchange arg0) throws HandlerException {
            // Here logic to handle with messages
        }

        @Override
        public void handleFault(Exchange arg0) throws HandlerException {
            // Here logic to handle with faults
        }
    });
You can reuse this ExchangeHandler by making it a named class (not anonymous).

14.10.5.1. Multiple Invocations of a Single Method

In the case of multiple invocation of the same method, the ExchangeHandler keeps track of the invocation number, in case it has to answer with different messages:
testKit.replaceService(qname, new ExchangeHandler() {
        int call=1;

        @Override
        public void handleMessage(Exchange exchange) throws HandlerException {
            if (call++ == 1){ // First call
                // Do whatever wants to be done as result of this operation call, and return the expected output
                Result result = ...; / Result is return type for operation store
                exchange.send(exchange.createMessage().setContent(result));
            }else if (call++ == 2){ // Second call
                // Do whatever wants to be done as result of this operation call, and return the expected output
                Result result = ...; / Result is return type for operation store
                exchange.send(exchange.createMessage().setContent(result));
            }else{
                throw new HandlerException("This mock should not be called more than 2 times");
            }
        }

        @Override
        public void handleFault(Exchange exchange) throws HandlerException {
            // Here logic to handle with faults
        }
    });

14.10.5.2. Multiple Invocations of Different Methods

In the case of multiple invocation of different methods, the ExchangeHandler checks for operation name, to know which method is being invoked:
testKit.replaceService(qname, new ExchangeHandler() {

        @Override
        public void handleMessage(Exchange exchange) throws HandlerException {
            if (exchange.getContract().getProviderOperation().getName().equals("store")){
                // Do whatever wants to be done as result of this operation call, and return the expected output
                Result result = ...; / Result is return type for operation store
                exchange.send(exchange.createMessage().setContent(result));
            }else if (exchange.getContract().getProviderOperation().getName().equals("getId")){
                // Do whatever wants to be done as result of this operation call, and return the expected output
                exchange.send(exchange.createMessage().setContent(1)); // This operation returns a Int
            }else{
                throw new HandlerException("No operation with that name should be executed");
            }
        }

        @Override
        public void handleFault(Exchange exchange) throws HandlerException {
            // Here logic to handle with faults
        }
    });

14.10.6. Setting Properties For a Test

You can use the PropertyMixIn property to set test properties in configurations, as shown below:
   private PropertyMixIn pmi;

   ...
   pmi.set("test.property.name", "test");
   pmi.set("test.property.name", Integer.valueOf(100));
   ...
   pmi.get("test.property.name");
   ...

14.10.7. Testing a Deployed Service with HTTPMixin

Use HTTPMixin to test a deployed service, as shown below:
@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(
        scanners = TransformSwitchYardScanner.class,
        mixins = {CDIMixIn.class, HTTPMixIn.class})
public class WebServiceTest {

    private HTTPMixIn httpMixIn;

    @Test
    public void invokeWebService() throws Exception {
        // Use the HttpMixIn to invoke the SOAP binding endpoint with a SOAP input (from the test classpath)
        // and compare the SOAP response to a SOAP response resource (from the test classpath)...
        httpMixIn.setContentType("application/soap+xml");
        httpMixIn.postResourceAndTestXML("http://localhost:18001/service-context/ServiceName", "/xml/soap-request.xml", "/xml/soap-response.xml");
    }
}
You can also use HTTPMixin from a main class, as shown below:
    /**
     * Only execution point for this application.
     * @param ignored not used.
     * @throws Exception if something goes wrong.
     */
    public static void main(final String[] ignored) throws Exception {

        HTTPMixIn soapMixIn = new HTTPMixIn();
        soapMixIn.initialize();

        try {
            String result = soapMixIn.postFile(URL, XML);
            System.out.println("SOAP Reply:\n" + result);
        } finally {
            soapMixIn.uninitialize();
        }
    }

14.10.8. Creating an Embedded WebService to Test a Component

In situations where you wish to only test a single component, you can expose it dynamically as a WebService and invoke it, as shown below:
import javax.xml.ws.Endpoint;
...

@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(
        config = SwitchYardTestCaseConfig.SWITCHYARD_XML,
        scanners = {TransformSwitchYardScanner.class},
        mixins = {HTTPMixIn.class})
public class CamelSOAPProxyTest {

    private static final String WEB_SERVICE = "http://localhost:8081/MyService";

    private HTTPMixIn _http;
    private Endpoint _endpoint;

    @BeforeDeploy
    public void setProperties() {
        System.setProperty("org.switchyard.component.http.standalone.port", "8081");
    }

    @Before
    public void startWebService() throws Exception {
        _endpoint = Endpoint.publish(WEB_SERVICE, new ReverseService());
    }

    @After
    public void stopWebService() throws Exception {
        _endpoint.stop();
    }

    @Test
    public void testWebService() throws Exception {
        _http.postResourceAndTestXML(WEB_SERVICE, "/xml/soap-request.xml", "/xml/soap-response.xml");
    }
}

14.10.9. Testing a Deployed Service with HornetQMixIn

When you need to test an application that has a JMS binding, you may want to test with the binding itself. In such cases, you can use HornetQMixIn. HornetQMixIn gets its configuration from the following two files, which must be present on the classpath for the test:
  • hornetq-configuration.xml: This file contains the configuration for the HornetQ server.
    <configuration xmlns="urn:hornetq">
    
            <paging-directory>target/data/paging</paging-directory>
            <bindings-directory>target/data/bindings</bindings-directory>
            <persistence-enabled>false</persistence-enabled>
            <journal-directory>target/data/journal</journal-directory>
            <journal-min-files>10</journal-min-files>
            <large-messages-directory>target/data/large-messages</large-messages-directory>
            <security-enabled>false</security-enabled>
    
            <connectors>
                    <connector name="invm-connector">
                            <factory-class>org.hornetq.core.remoting.impl.invm.InVMConnectorFactory</factory-class>
                    </connector>
                    <connector name="netty-connector">
                     <factory-class>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</factory-class>
                     <param key="port" value="5545"/>
          </connector>
            </connectors>
    
            <acceptors>
                    <acceptor name="invm-acceptor">
                            <factory-class>org.hornetq.core.remoting.impl.invm.InVMAcceptorFactory</factory-class>
                    </acceptor>
                    <acceptor name="netty-acceptor">
                            <factory-class>org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory</factory-class>
                            <param key="port" value="5545"/>
                    </acceptor>
            </acceptors>
    
    </configuration>
  • hornetq-configuration.xml: This file contains the definition of the connection factories, queues, and topics.
    <configuration xmlns="urn:hornetq">
    
       <connection-factory name="ConnectionFactory">
          <connectors>
            <connector-ref connector-name="invm-connector"/>
          </connectors>
    
          <entries>
             <entry name="ConnectionFactory"/>
          </entries>
       </connection-factory>
    
       <queue name="TestRequestQueue">
          <entry name="TestRequestQueue"/>
       </queue>
       <queue name="TestReplyQueue">
          <entry name="TestReplyQueue"/>
       </queue>
    
    </configuration>
To use HornetQMixIn in a test, you need to get a reference to the MixIn and use the appropriate mixin methods, as shown below:
@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(
        config = SwitchYardTestCaseConfig.SWITCHYARD_XML,
        mixins = {CDIMixIn.class, HornetQMixIn.class}
)

public class JmsBindingTest {

    private HornetQMixIn _hqMixIn;


    @Test
    public void testHelloService() throws Exception {
        Session session = _hqMixIn.getJMSSession();
        MessageProducer producer = session.createProducer(HornetQMixIn.getJMSQueue(REQUEST_NAME));
        Message message = _hqMixIn.createJMSMessage(createPayload(NAME));
        producer.send(message);

        MessageConsumer consumer = session.createConsumer(HornetQMixIn.getJMSQueue(REPLY_NAME));
        message = consumer.receive(3000);
        String reply = _hqMixIn.readStringFromJMSMessage(message);
        SwitchYardTestKit.compareXMLToString(reply, createExpectedReply(NAME));
    }

    @Before
    public void getHornetQMixIn() {
        _hqMixIn = _testKit.getMixIn(HornetQMixIn.class);
    }

You can also test from a standalone client, as shown below:
public static void main(final String[] args) throws Exception {

        HornetQMixIn hqMixIn = new HornetQMixIn(false)
                                    .setUser(USER)
                                    .setPassword(PASSWD);
        hqMixIn.initialize();

        try {
            Session session = hqMixIn.getJMSSession();
            final MessageProducer producer = session.createProducer(HornetQMixIn.getJMSQueue(REQUEST_NAME));
            producer.send(hqMixIn.createJMSMessage("<....>");
            System.out.println("Message sent. Waiting for reply ...");

            final MessageConsumer consumer = session.createConsumer(HornetQMixIn.getJMSQueue(REPLY_NAME));
            Message message = consumer.receive(3000);
            String reply = hqMixIn.readStringFromJMSMessage(message);
            System.out.println("REPLY: \n" + reply);
        } finally {
            hqMixIn.uninitialize();
        }

    }

14.10.10. Testing a Deployed Service with TransactionMixIn

You can use TransactionMixIn to test your required services with a transaction. TransactionMixIn with combination of CDIMixIn injects a UserTransaction object when required. If you need explicit access, you can use @Inject in the UserTransaction object. otherwise, it is injected in SwitchYard’s functionalities. This MixIn introduces NamingMixIn, as it is a required dependency.
@SwitchYardTestCaseConfig(
    config = SwitchYardTestCaseConfig.SWITCHYARD_XML,
    mixins = {CDIMixIn.class, TransactionMixIn.class}
)
public YourClass{
    ....
}
This binds the following objects into the JNDI tree:
  • TransactionManager: java:jboss/TransactionManager
  • UserTransaction: java:jboss/UserTransaction
  • TransactionSynchronizationRegistry: java:jboss/TransactionSynchronizationRegistry
If you need access to the provided objects, you can use the MixIn to get a reference, as shown below:
    private TransactionMixIn transaction;
    ....
    transaction.getUserTransaction();
    transaction.getTransactionManager();
    transaction.getSynchronizationRegistry();
This mixin creates transactional logs in target/tx-store and uses Arjuna Transactions Provider (com.arjuna.ats.jta).

14.10.11. Testing With a Different SwitchYard Configuration File

You can use the following annotation on the test class and create your reduced <switchyard-XXXX.xml> within the test/resources folder at the same package level as your test class:
@SwitchYardTestCaseConfig(config = "switchyard-XXXXX.xml", mixins = {.....})

14.10.12. 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 you must allow activators to be selectively enabled or disabled based on your test configuration. In the example below, SOAP bindings are excluded from all tests. This means that SOAP gateway bindings are not activated when the test framework loads the application.
@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(config = "testconfigs/switchyard-01.xml" exclude="soap")
public class NoSOAPTest  {
   ...
}
The example below includes only CDI bean services as defined in the application descriptor:

@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(config = "testconfigs/switchyard-02.xml" include="bean")
public class BeanServicesOnlyTest  {
...
}
You may need to add some procedures before you perform the test. The JUnit @Before operation is invoked immediately after the application is deployed. However, you can not use it if you expect something to happen before deployment.

14.10.13. Preparing Procedure for Test

JUnit @Before operation is invoked right after the application is deployed. So, you can not use @Before operation if you expect something before deployment. Use @BeforeDeploy annotation when you need to add some procedures before a test is performed.

14.10.14. Testing a Camel Binding

If you are exposing services with a camel binding, you can test it by getting the CamelContext and then creating a ProducerTemplate as shown below:
@RunWith(SwitchYardRunner.class)
@SwitchYardTestCaseConfig(
        config = SwitchYardTestCaseConfig.SWITCHYARD_XML,
        mixins = { CDIMixIn.class })
public class ExampleTest {

    private SwitchYardTestKit testKit;

    @Test
    public void testIntake() throws Exception {
        ServiceDomain domain = testKit.getServiceDomain();
        CamelContext ctx = (CamelContext)domain.getProperty("CamelContextProperty");
        ProducerTemplate producer = ctx.createProducerTemplate();
        producer.sendBody("direct://HelloService", "Message content");
    }
}
You can test a service like the one defined below that has a camel binding:
<sca:service name="Hello/HelloService" promote="Hello/HelloService">
   <sca:interface.java interface="org.jboss.example.ExampleService"/>
   <camel_1:binding.uri name="camel1" configURI="direct://HelloService"/>
</sca:service>