Now that mixins have been split out into individual modules, every SY application will have to specifically identify which mixins will be used for test support.  At a low-level, this basically means that an application which used to use the JCA, Naming, and CDI mixins before could get all dependencies with this:

<dependency>
   <groupId>org.switchyard</groupId>
   <artifactId>switchyard-test</artifactId>
   <scope>test</scope>
</dependency>

The above would bring the entire testing world in before modularization.  Now that the test stuff is split up, we need to add the following dependencies to the application pom.xml :

<dependency>
   <groupId>org.switchyard.components</groupId>
   <artifactId>switchyard-component-test-mixin-cdi</artifactId>
   <scope>test</scope>
</dependency>
<dependency>
   <groupId>org.switchyard.components</groupId>
   <artifactId>switchyard-component-test-mixin-hornetq</artifactId>
   <scope>test</scope>
</dependency>
<dependency>
   <groupId>org.switchyard.components</groupId>
   <artifactId>switchyard-component-test-mixin-jca</artifactId>
   <scope>test</scope>
</dependency>

Rob and I had a brief chat on IRC about the right way to do this from a user perspective.  One option is to simply add these dependencies as a user enables specific SY capabilities.  Today, if a user selects the Bean service capability, we add a dependency on the bean component.  We could also add a test-scoped dependency on the CDI MixIn as well.  This seems user friendly, although there's not always a direct correlation between a mixin and a component.  We also don't know if the user plans on testing (although I hope they do!).  Another option is to have a similar checkbox style view for test capabilities as we have for service/gateway capabilities today.  This gives the user independent control over which MixIn dependencies are included in their project. 

I think we should actually do both.  I suggest we start with the checkbox style because I think that's mandatory to give the user proper control over project dependencies.  Then we implement the "smart" dependency option that's correlated to a user's service/gateway capability choices.

BTW, I think we should always keep the switchyard-test dependency around as we do today.  I know that the other mixins will pull this in transitively, but it can be used without any mixins and I don't see a lot of overhead in keeping it around.