Apache Camel provides a powerfull unit testing framework that developpers use since years and which name is Camel Test Kit. This unit testing framework consists in a number of classes on top of JUnit that facilitate Camel routes unit testing. Among these classes, one of the developer’s prefered is ProducerTemplate which represents a very convenient way to send Camel messages to Camel routes, for testing purposes. But when it comes to deploy Camel routes into the new Fuse Service Works application server, the developer skeptically discovers that, while SwitchYard comes with a very strong unit testing frameworks supporting HTTP, CDI, HornetQ/JMS and Smooks, the old good Camel Test Kit is not supported. At least this is what the Red Hat technical support will advise to the developers submiting tickets in order to complain that statements like :

@Test public void testStartService() throws Exception
{
  template.sendBody ("switchyard://HelloWorldComponentService", "Hello World !");
}

raise the following exception :

java.lang.ClassCastException: org.apache.camel.impl.DefaultCamelContext cannot be cast to org.switchyard.common.camel.SwitchYardCamelContext at …

What happens here is that the Camel ProducerTemplate uses a CamelDefaultContext while producing message to SwitchYard endpoints obviously requires a SwitchYardCamelContext instance. And the SwitchYardCamelContext cannot be casted to a CamelDefaultContext instance. How then is one supposed to use the Camel unit test framework with SwitchYard ?

The Red Hat support will tell you that this is simply not supported and that, if you want to test Camel routes using HTTP or JMS endpoints, then you may do it using SwitchYard MixIn like explained here  https://docs.jboss.org/author/display/SWITCHYARD/Testing, otherwise you need to use real test clients like in integration/functional testing. This is what happened to me and, after a several days debate at the end of which they simply closed my ticket without my agreement, I decided to submit the same case to the SwitchYard community forum. And guess what ? One hour later, thanks to Keith Baboo, I got my solution. Given a SCA service like the following :

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

One may test it like this :

@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");  
  }  
}  

The way we instantiate the Camel ProducerTemplate here is very different compared to the way we do it in plain vanilla Camel and, since this is not documented, the developer would probably have difficulties to guess it. Hence, I wanted to document it here, waiting that the official documentation be updated and hoping that the Red Hat FSW technical support will also read it. The morality is that, sometimes, it is not worth paying expansive technical support because free users forum might be more proficient and, in any case, more polite and respectfull.

Thanks Keith !