Hi Jeremy, Thanks for the clarifications... a few inline one lines responses, but nothing that really needs an answer :)
WRT the plugin... would be interested in this, but not sure I could commit to anything at the mo - if things change then I'll post to the list again Cheers, Dan On 05/03/07, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
On Mar 5, 2007, at 9:08 AM, Dan Murphy wrote: > Hi Jeremy, > > I think what you're suggesting is along the lines of the 'whilst I > could > deploy nested composites' thought (I may have misunderstood you > though)... > I would have liked to deploy two separate composites as it seemed > likely > that the code path could be different when using nested composites > (which I > also planned to do, presuming these would be optimised).... this > way I would > end up with tests for databindings test for : > inter component > inter composite (in a nested composite) > inter composite (not nested) > Does that make sense ? Not really. There may be some confusion here over "deploy." In SCA you don't "deploy" applications in the traditional sense - you contribute implementations to a domain and then assemble component hierarchies from them.
Interesting, I appreciated that there was no deploy (ala J2EE) but had assumed that composites were isolated. I guess I misinterpreted the reasons behind Sebastien's separation to run under different vms... The itest plugin is designed for users to test their applications. If
you want to test the internals of a databinding or how it is activated by the fabric, I'd suggest testing that directly. You can get much better coverage using the internal SPIs than you can with a fairly convoluted multi-vm setup. And that wouldn't involve "deploying" anything.
I kept away from the SPIs so that the itests could prove end to end that the databindings were working as expected. It does mean it will need more tests and analysis of code coverage etc, but also gave me the chance to get to grips with SCA better... I guess I'm a bit of a masochist :) If you look at trunk, we optimize away the implementations of
composites and just have connections between leaf components so all of that would come down to "inter component." There are two forms that can take: * connection between two components in the same VM * binding of component service or reference to a transport
Good news, makes the tests valid for all situations since it'll only need the one interop suite... had thought I'd end up with one for each of the 3 scenarios. Each of those only requires a single VM to test.
> > Ideally I would like to do the inter composite (not nested) between > 2 jvms, > Sebastien's did something similar (although in a single JVM) by > instantiating a second SCATestCase to deploy additional composites ( > https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca- > java-integration/testing/sca/itest/bindings/bindingsclient/src/test/ > java/org/apache/tuscany/sca/itest/WSBindingsClientTestCase.java > ) > I was wondering if the there are plans to improve iTest (& plugin if > applicable) to facilitate multi-vm / non-nested multiple composite > testing. The itest plugin works by "deploying" a test composite to a local domain running inside Maven. With SCA's abstraction of the environment from the programming model, that provides quite a lot of support for integration testing of a composite. I think it would be good to support "deployment" to a different domain, which really means contributing the composite to a remote server through a remote ContributionService - something a bit like Cargo would be good to have. Another improvement would be a mock framework for composites that allow the simulation of external references - I've been wondering about integrating the itest plugin with EasyMock for that. Those are both just ideas rather than "plans" - if this is something that interests you jump on in. -- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
