We're looking at this JIRA, which is/might-be about adding the ability to selectivly activate specific components during unit test execution.
Keith came across this on his travels to Japan/Aus. Basically... you have an application which has an associated switchyard.xml configuration. All is rosie when the app is deployed to the full AS container, but writing tests for the application can get hairy because the test is always trying to activate everything, even when it might not need to, or (more importantly), is unable to (because it doesn't have everything it needs around it).
We need a mechanism in the test framework that allows the developer to indicate what components should/shouldn't be deployed as part of the test.
Options that have been talked about:
- Tests need to have trimmed down configs, only containing the components that need to be deployed. Advantage of this is clarity in the tests ... wysiwyt ( )... disadvantage is obviously the repitition/duplication of configs in the test and the potential maintenance issues that go with that.
- Use the defined MixIns to decide which components are activated. Advantage of this is that it might just work and the developer doesn't have to do any additional work. Disadvantage... it assumes there's always a 1:1 relationship between the components you'll want/need to activate and the MixIns you'll be using in your test.
- Explicitly declare the Activator types to be executed as part of the test deployment. Advantage of this is that it's explicit. Disadvantage is that it's dragging the developer down into layers of SwitchYard that they prob don't need to be working at (wtf is an activator and which ones should I configure?).
- Specify XPath expressions to identify the fragments of the config to be included/excluded in the deployment process (i.e. activated). Advantage is that it's explicit and you're not duplicating configs (as in #1) - you're pointing out the fragments of the apps config that you want activated in the test. Disadvantage... might not be feasible because of how configs are often generated at build time (by scanners)... the developer can't see the config model they're going to be using and so prob can't specify the XPaths.
The only ones I can really see working reliably atm are #1 and #3. All options have their disadvantages, but at least (imo) the disadvantages of #1 and #3 are predictable and workable. I think options #2 and #4 are a bit hokey and would just lead to a myriad of other issues.
Any other options/opinions people can think of?