You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2006/04/25 14:19:14 UTC
WS interop/intergation/functional testing
There's been lots of debate on testing and no real agreement yet on what to
do and this is blocking getting the WS interop testing setup which are part
of the Wiki release plan. I'd like to propose the following and would
appreciate any comments or suggestions. We need to move this along so I'll
use lazy consensus, this is whats happening unless you provide a specific
alternative.
Create a new folder under testing called 'interop' . Interop may not be the
best name, feel free to suggest alternatives.
In testing/interop there will be two other folders, 'local', and 'remote'.
testing/interop/remote will contain WS test clients that make WS invocations
out to remote services on the Internet, so you'll need a network connection
to run these and they'll probably be a little slow.
testing/interop/local will include implementations of the WS services used
by all the clients in the remote folder. It will also have clients to invoke
those services but they'll just be extending the client code in the remote
folder to override the endpoint used to be the local service but without
requiring too much code duplication of the client code.
Within the local and remote folders there will be separate projects for each
set of tests, so projects for whitemesa, aspnetround3, amazon etc.
These tests are using the actual SCA client APIs, they're not gong to be
fudging things like the existing WS test in the tomcat integration tests.
The testing/interop/local services need to be deployed and run in tomcat to
work, so that will be done by the existing testing/tomcat stuff. I haven't
quite though this part through yet, I guess that means having testing/tomcat
get all the testing/interop/local sevices deployed and adding to
testing/tomcat an interop test project which calls all the testcases in
testing/interop/local. It doesn't seem perfect to require having
testing/tomcat/interop as well as testing/interop, is there a better/easier
way to do this?
So with that config you can run all the testing/interop/local tests to test
out the Tuscany WS entryPoint and externalService function. Or you can run
all the testing/interop/remote tests to verify interaction with real
non-Tuscany systems.
For now I wont even mention the question of when any of these tests should
get run as part of a build process :-)
Any comments or suggestions?
...ant
Re: WS interop/intergation/functional testing
Posted by Daniel Kulp <da...@iona.com>.
Jim,
> Dan, you mentioned on chat that Celtix has a mechanism for doing
> integration testing. I raised this question a several times on the
> list (we have a lot of duplicate "mock" code". Could you describe
> what you guys have done and if you think it is appropriate for us? I
> think you are running into some problems related to this as you write
> unit tests for the Celtix binding since many of the mock classes and
> factories will need to be copied.
There are a few parts to that question:
1) Code re-use in tests - For celtix, we created a "testutils" project
that puts a lot of common utilities and such as "src/java/main", not test
code. Thus, the other projects that need it just depend on that project
with <scope>test</scope>. There isn't any copying of classes and such
from one project to a bunch of other projects.
2) The testutils project also contains a bunch of "common" test wsdls.
doc/lit, doc/lit wrapped, rpc/lit, JMS endpoints, XML bindings (not
soap), a "type test" wsdl (contains about 150 different schema types with
"echo" operations for each), etc.... As part of the testutils build
WSDL2Java is run on all of them to generate interfaces and types. There
are also sample "server implementations" for all of them in the
testutils. Thus, if a test needs a server implementation of something,
they are already available. (the tools project where java2wsdl lives
must be built before the runtime parts which is different than tuscany.
How do people that want to test things use generated code in tests
currently in tuscany? Is the code just checked in? The only place we
allow that is for tests in the tools package itself. All the others are
NOT allowed to check in generated code. The code must be generated as
part of the build, but mostly we just rely on stuff from testutils.)
3) Celtix supports a "pipe" protocol/url for soap:address. Thus, in a
test, you can pop up a server on a "pipe" and hit it with a client.
This involves no tcpip traffic, not HTTP port, etc... Thus, testing
complete round trips in a single VM is a bit easier and lighter weight.
4) For more complex "integration" tests (we call them system tests, also
used in our Axis interop tests), the testutils package also contains
utilities for setting up, forking, and controllling background servers.
Thus, in our JUnit style tests, in the "setUp" method (or more likely in
the suite(..) method), you can just call "startServer(new ServerClass())"
type of method to start a background server process. (again, most of
the Server classes are also part of the testutils project and available
everywhere).
5) Server behavior: the "normal" mechanism for creating/writing/starting
a server in Celtix is NOT to deploy a war into tomcat or some other web
application. MOST of our users don't use any type of app server or
servlet engine or anything for hosting their servers. (Celtix does
support it, but it's not the normal case) In celtix, (with the JAX-WS
apis's) you can just create a main method with something like:
Endpoint.publish(wsdlurl, new ServerImpl());
and Celtix will startup Jetty (if the wsdl is HTTP), or a JMS queue (if
JMS, JMS broker does need starting externally first) or whatever else is
needed. This also makes testing a LOT easier as you don't need to
figure out how to deploy to tomcat, control tomcat, etc...
6) Mock stuff: we use easymock. We don't really have any Mock things
hand coded and checked in. We just allow easymock to create them as
needed.
I hope this helps answer some of the questions. I'd be happy to expand
on any of those a bit more if needed. I guess the two things I'd like
some sort of solution to are:
1) Utility code re-use (for things like Mock factories and such)
2) Generated code use - currently impossible as the SCA tools are built
too late in the cycle. We can currently just use generated SDO code.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
Re: WS interop/intergation/functional testing
Posted by ant elder <an...@gmail.com>.
On 4/26/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
<snip/>
- can we have a single client test suite and externalize the endpoints
> that it talks to, with a Maven configuration for example?
I don't know, can we? I agree that would make things much simpler, having
the two sets of clients just to change the endpoint is ugly. I did wonder if
this was possible but don't know enough about maven so did it the ugly way.
Could someone provide more details on how to do this?
Thanks,
...ant
Re: WS interop/intergation/functional testing
Posted by Jim Marino <jm...@myromatours.com>.
On Apr 25, 2006, at 5:58 PM, Jean-Sebastien Delfino wrote:
> Jim Marino wrote:
>
>>
>> On Apr 25, 2006, at 6:28 AM, Jeremy Boynes wrote:
>>
>>
>>> Generally I like this approach - I do have a couple of small
>>> comments inline.
>>>
>>> On 4/25/06, ant elder <an...@gmail.com> wrote:
>>>
>>>
>>>>
>>>> Create a new folder under testing called 'interop' . Interop may
>>>> not be the
>>>> best name, feel free to suggest alternatives.
>>>>
>>>>
>>>>
>>>
>>> interop makes sense - +1
>>>
>>>
>>>
>>>> In testing/interop there will be two other folders, 'local', and
>>>> 'remote'.
>>>>
>>>> testing/interop/remote will contain WS test clients that make WS
>>>> invocations
>>>> out to remote services on the Internet, so you'll need a network
>>>> connection
>>>> to run these and they'll probably be a little slow.
>>>>
>>>>
>>>>
>>>
>>> "client" would also be an alternative to "remote"
>>>
>>> I assume these will be J2SE clients that can just be run with maven
>>> and that they use WS ExternalServices to talk to the remote
>>> services.
>>> Will there be multiple implementations of the test clients in
>>> different languages?
>>>
>>
>> Is there a reason you were thinking about why these wouldn't be
>> JUnit-based or is that considered J2SE?
>>
>>
>>>
>>>
>>>
>>>> testing/interop/local will include implementations of the WS
>>>> services used
>>>> by all the clients in the remote folder. It will also have
>>>> clients to invoke
>>>> those services but they'll just be extending the client code in
>>>> the remote
>>>> folder to override the endpoint used to be the local service but
>>>> without
>>>> requiring too much code duplication of the client code.
>>>>
>>>>
>>>>
>>>
>>> Perhaps "server" as an alternative to "local"
>>> Will we have to implement these services or are there existing
>>> versions we can use?
>>> Are there other non-SCA clients that can be used to call them?
>>>
>>>
>>>
>>>> Within the local and remote folders there will be separate
>>>> projects for each
>>>> set of tests, so projects for whitemesa, aspnetround3, amazon etc.
>>>>
>>>> These tests are using the actual SCA client APIs, they're not
>>>> gong to be
>>>> fudging things like the existing WS test in the tomcat
>>>> integration tests.
>>>> The testing/interop/local services need to be deployed and run
>>>> in tomcat to
>>>> work, so that will be done by the existing testing/tomcat stuff.
>>>> I haven't
>>>> quite though this part through yet, I guess that means having
>>>> testing/tomcat
>>>> get all the testing/interop/local sevices deployed and adding to
>>>> testing/tomcat an interop test project which calls all the
>>>> testcases in
>>>> testing/interop/local. It doesn't seem perfect to require having
>>>> testing/tomcat/interop as well as testing/interop, is there a
>>>> better/easier
>>>> way to do this?
>>>>
>>>>
>>>>
>>>
>>> This should not depend on a special Tomcat installation but
>>> should be
>>> deployable to our normal Tomcat distribution (or any other distro we
>>> do) - that way we know the distro that users would actually download
>>> is being tested.
>>>
>>>
>> +1 on this particularly as we add more host environments
>>
>>
>>> I'm not sure you really need the special clients here - just run the
>>> server and then run the real clients (from "remote") against it.
>>> That
>>> way we know our real interop clients talk to our real server with no
>>> "fudging."
>>>
>>>
>> I also like this given that if we test against our own servers
>> it's not interop
>>
>>>
>>>
>>>> So with that config you can run all the testing/interop/local
>>>> tests to test
>>>> out the Tuscany WS entryPoint and externalService function. Or
>>>> you can run
>>>> all the testing/interop/remote tests to verify interaction with
>>>> real
>>>> non-Tuscany systems.
>>>>
>>>>
>>>>
>>>
>>> Interop is all about working with non-Tuscany systems. I think
>>> having
>>> the ability to run their clients against our server is very
>>> important.
>>>
>>
>> Ant or someone more familiar with Axis, I assume there are some
>> mechanisms at Apache for setting this type of thing up?
>>
>>>
>>>
>>>> For now I wont even mention the question of when any of these
>>>> tests should
>>>> get run as part of a build process :-)
>>>>
>>>>
>>>>
>>>
>>> Given the dependencies (e.g. on remote servers, other people's
>>> clients) then I don't think these should be run as part of the
>>> build.
>>> This should be done in a controlled environment on a periodic basis,
>>> and at least once with any release candidate.
>>>
>>>
>>>
>>>> Any comments or suggestions?
>>>>
>>>>
>>>>
>>>
>>> Thanks
>>> --
>>> Jeremy
>>>
>>>
>>
>>
>>
>
> +1 from me on all of this.
>
> I am assuming that the client side tests are Junit tests.
> I like Jeremy's proposal to name these client / server.
> I agree that we need to run these tests on top of our actual distro.
>
> Two questions:
> - can we run this daily with continuum?
> - can we have a single client test suite and externalize the
> endpoints that it talks to, with a Maven configuration for example?
> (this would be simpler than the initial template that I had checked
> in, which had common test code but still required different test
> cases to talk to our server and the remote test server)
>
I'd like to add that I think we need unit and "integration" testing
run as part of the build which covers some of the expected interop
behavior. In other words, we should have good enough coverage in our
build where a basic interop test (e..g not serializing something
properly) surprises us. I was thinking the integration tests would
not deploy to a servlet container but would use mock components and
programmatically verify messages flowing in and out of entry points
and external services. It would also be nice to have a generic unit/
integration test harness that could be run using different ws
bindings such as Axis/Celtix. Does this make sense to people?
Dan, you mentioned on chat that Celtix has a mechanism for doing
integration testing. I raised this question a several times on the
list (we have a lot of duplicate "mock" code". Could you describe
what you guys have done and if you think it is appropriate for us? I
think you are running into some problems related to this as you write
unit tests for the Celtix binding since many of the mock classes and
factories will need to be copied.
Thanks,
Jim
> --
> Jean-Sebastien
>
>
Re: WS interop/intergation/functional testing
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jim Marino wrote:
>
> On Apr 25, 2006, at 6:28 AM, Jeremy Boynes wrote:
>
>> Generally I like this approach - I do have a couple of small comments
>> inline.
>>
>> On 4/25/06, ant elder <an...@gmail.com> wrote:
>>
>>>
>>> Create a new folder under testing called 'interop' . Interop may not
>>> be the
>>> best name, feel free to suggest alternatives.
>>>
>>>
>>
>> interop makes sense - +1
>>
>>
>>> In testing/interop there will be two other folders, 'local', and
>>> 'remote'.
>>>
>>> testing/interop/remote will contain WS test clients that make WS
>>> invocations
>>> out to remote services on the Internet, so you'll need a network
>>> connection
>>> to run these and they'll probably be a little slow.
>>>
>>>
>>
>> "client" would also be an alternative to "remote"
>>
>> I assume these will be J2SE clients that can just be run with maven
>> and that they use WS ExternalServices to talk to the remote services.
>> Will there be multiple implementations of the test clients in
>> different languages?
>
> Is there a reason you were thinking about why these wouldn't be
> JUnit-based or is that considered J2SE?
>
>>
>>
>>> testing/interop/local will include implementations of the WS
>>> services used
>>> by all the clients in the remote folder. It will also have clients
>>> to invoke
>>> those services but they'll just be extending the client code in the
>>> remote
>>> folder to override the endpoint used to be the local service but
>>> without
>>> requiring too much code duplication of the client code.
>>>
>>>
>>
>> Perhaps "server" as an alternative to "local"
>> Will we have to implement these services or are there existing
>> versions we can use?
>> Are there other non-SCA clients that can be used to call them?
>>
>>
>>> Within the local and remote folders there will be separate projects
>>> for each
>>> set of tests, so projects for whitemesa, aspnetround3, amazon etc.
>>>
>>> These tests are using the actual SCA client APIs, they're not gong
>>> to be
>>> fudging things like the existing WS test in the tomcat integration
>>> tests.
>>> The testing/interop/local services need to be deployed and run in
>>> tomcat to
>>> work, so that will be done by the existing testing/tomcat stuff. I
>>> haven't
>>> quite though this part through yet, I guess that means having
>>> testing/tomcat
>>> get all the testing/interop/local sevices deployed and adding to
>>> testing/tomcat an interop test project which calls all the testcases in
>>> testing/interop/local. It doesn't seem perfect to require having
>>> testing/tomcat/interop as well as testing/interop, is there a
>>> better/easier
>>> way to do this?
>>>
>>>
>>
>> This should not depend on a special Tomcat installation but should be
>> deployable to our normal Tomcat distribution (or any other distro we
>> do) - that way we know the distro that users would actually download
>> is being tested.
>>
> +1 on this particularly as we add more host environments
>
>> I'm not sure you really need the special clients here - just run the
>> server and then run the real clients (from "remote") against it. That
>> way we know our real interop clients talk to our real server with no
>> "fudging."
>>
> I also like this given that if we test against our own servers it's
> not interop
>>
>>> So with that config you can run all the testing/interop/local tests
>>> to test
>>> out the Tuscany WS entryPoint and externalService function. Or you
>>> can run
>>> all the testing/interop/remote tests to verify interaction with real
>>> non-Tuscany systems.
>>>
>>>
>>
>> Interop is all about working with non-Tuscany systems. I think having
>> the ability to run their clients against our server is very important.
>
> Ant or someone more familiar with Axis, I assume there are some
> mechanisms at Apache for setting this type of thing up?
>>
>>> For now I wont even mention the question of when any of these tests
>>> should
>>> get run as part of a build process :-)
>>>
>>>
>>
>> Given the dependencies (e.g. on remote servers, other people's
>> clients) then I don't think these should be run as part of the build.
>> This should be done in a controlled environment on a periodic basis,
>> and at least once with any release candidate.
>>
>>
>>> Any comments or suggestions?
>>>
>>>
>>
>> Thanks
>> --
>> Jeremy
>>
>
>
+1 from me on all of this.
I am assuming that the client side tests are Junit tests.
I like Jeremy's proposal to name these client / server.
I agree that we need to run these tests on top of our actual distro.
Two questions:
- can we run this daily with continuum?
- can we have a single client test suite and externalize the endpoints
that it talks to, with a Maven configuration for example?
(this would be simpler than the initial template that I had checked in,
which had common test code but still required different test cases to
talk to our server and the remote test server)
--
Jean-Sebastien
Re: WS interop/intergation/functional testing
Posted by Jeremy Boynes <jb...@apache.org>.
On 4/25/06, Jim Marino <jm...@myromatours.com> wrote:
> >
> > I assume these will be J2SE clients that can just be run with maven
> > and that they use WS ExternalServices to talk to the remote services.
> > Will there be multiple implementations of the test clients in
> > different languages?
>
> Is there a reason you were thinking about why these wouldn't be JUnit-
> based or is that considered J2SE?
>
I was thinking J2SE host environment for SCA, probably kicked off from
JUnit - or, yes, I was considering that as J2SE ;-)
--
Jeremy
Re: WS interop/intergation/functional testing
Posted by Jim Marino <jm...@myromatours.com>.
On Apr 25, 2006, at 6:28 AM, Jeremy Boynes wrote:
> Generally I like this approach - I do have a couple of small
> comments inline.
>
> On 4/25/06, ant elder <an...@gmail.com> wrote:
>
>>
>> Create a new folder under testing called 'interop' . Interop may
>> not be the
>> best name, feel free to suggest alternatives.
>>
>>
>
> interop makes sense - +1
>
>
>> In testing/interop there will be two other folders, 'local', and
>> 'remote'.
>>
>> testing/interop/remote will contain WS test clients that make WS
>> invocations
>> out to remote services on the Internet, so you'll need a network
>> connection
>> to run these and they'll probably be a little slow.
>>
>>
>
> "client" would also be an alternative to "remote"
>
> I assume these will be J2SE clients that can just be run with maven
> and that they use WS ExternalServices to talk to the remote services.
> Will there be multiple implementations of the test clients in
> different languages?
Is there a reason you were thinking about why these wouldn't be JUnit-
based or is that considered J2SE?
>
>
>> testing/interop/local will include implementations of the WS
>> services used
>> by all the clients in the remote folder. It will also have clients
>> to invoke
>> those services but they'll just be extending the client code in
>> the remote
>> folder to override the endpoint used to be the local service but
>> without
>> requiring too much code duplication of the client code.
>>
>>
>
> Perhaps "server" as an alternative to "local"
> Will we have to implement these services or are there existing
> versions we can use?
> Are there other non-SCA clients that can be used to call them?
>
>
>> Within the local and remote folders there will be separate
>> projects for each
>> set of tests, so projects for whitemesa, aspnetround3, amazon etc.
>>
>> These tests are using the actual SCA client APIs, they're not gong
>> to be
>> fudging things like the existing WS test in the tomcat integration
>> tests.
>> The testing/interop/local services need to be deployed and run in
>> tomcat to
>> work, so that will be done by the existing testing/tomcat stuff. I
>> haven't
>> quite though this part through yet, I guess that means having
>> testing/tomcat
>> get all the testing/interop/local sevices deployed and adding to
>> testing/tomcat an interop test project which calls all the
>> testcases in
>> testing/interop/local. It doesn't seem perfect to require having
>> testing/tomcat/interop as well as testing/interop, is there a
>> better/easier
>> way to do this?
>>
>>
>
> This should not depend on a special Tomcat installation but should be
> deployable to our normal Tomcat distribution (or any other distro we
> do) - that way we know the distro that users would actually download
> is being tested.
>
+1 on this particularly as we add more host environments
> I'm not sure you really need the special clients here - just run the
> server and then run the real clients (from "remote") against it. That
> way we know our real interop clients talk to our real server with no
> "fudging."
>
I also like this given that if we test against our own servers it's
not interop
>
>> So with that config you can run all the testing/interop/local
>> tests to test
>> out the Tuscany WS entryPoint and externalService function. Or you
>> can run
>> all the testing/interop/remote tests to verify interaction with real
>> non-Tuscany systems.
>>
>>
>
> Interop is all about working with non-Tuscany systems. I think having
> the ability to run their clients against our server is very important.
Ant or someone more familiar with Axis, I assume there are some
mechanisms at Apache for setting this type of thing up?
>
>> For now I wont even mention the question of when any of these
>> tests should
>> get run as part of a build process :-)
>>
>>
>
> Given the dependencies (e.g. on remote servers, other people's
> clients) then I don't think these should be run as part of the build.
> This should be done in a controlled environment on a periodic basis,
> and at least once with any release candidate.
>
>
>> Any comments or suggestions?
>>
>>
>
> Thanks
> --
> Jeremy
>
Re: WS interop/intergation/functional testing
Posted by Jeremy Boynes <jb...@gmail.com>.
Generally I like this approach - I do have a couple of small comments inline.
On 4/25/06, ant elder <an...@gmail.com> wrote:
>
> Create a new folder under testing called 'interop' . Interop may not be the
> best name, feel free to suggest alternatives.
>
interop makes sense - +1
> In testing/interop there will be two other folders, 'local', and 'remote'.
>
> testing/interop/remote will contain WS test clients that make WS invocations
> out to remote services on the Internet, so you'll need a network connection
> to run these and they'll probably be a little slow.
>
"client" would also be an alternative to "remote"
I assume these will be J2SE clients that can just be run with maven
and that they use WS ExternalServices to talk to the remote services.
Will there be multiple implementations of the test clients in
different languages?
> testing/interop/local will include implementations of the WS services used
> by all the clients in the remote folder. It will also have clients to invoke
> those services but they'll just be extending the client code in the remote
> folder to override the endpoint used to be the local service but without
> requiring too much code duplication of the client code.
>
Perhaps "server" as an alternative to "local"
Will we have to implement these services or are there existing
versions we can use?
Are there other non-SCA clients that can be used to call them?
> Within the local and remote folders there will be separate projects for each
> set of tests, so projects for whitemesa, aspnetround3, amazon etc.
>
> These tests are using the actual SCA client APIs, they're not gong to be
> fudging things like the existing WS test in the tomcat integration tests.
> The testing/interop/local services need to be deployed and run in tomcat to
> work, so that will be done by the existing testing/tomcat stuff. I haven't
> quite though this part through yet, I guess that means having testing/tomcat
> get all the testing/interop/local sevices deployed and adding to
> testing/tomcat an interop test project which calls all the testcases in
> testing/interop/local. It doesn't seem perfect to require having
> testing/tomcat/interop as well as testing/interop, is there a better/easier
> way to do this?
>
This should not depend on a special Tomcat installation but should be
deployable to our normal Tomcat distribution (or any other distro we
do) - that way we know the distro that users would actually download
is being tested.
I'm not sure you really need the special clients here - just run the
server and then run the real clients (from "remote") against it. That
way we know our real interop clients talk to our real server with no
"fudging."
> So with that config you can run all the testing/interop/local tests to test
> out the Tuscany WS entryPoint and externalService function. Or you can run
> all the testing/interop/remote tests to verify interaction with real
> non-Tuscany systems.
>
Interop is all about working with non-Tuscany systems. I think having
the ability to run their clients against our server is very important.
> For now I wont even mention the question of when any of these tests should
> get run as part of a build process :-)
>
Given the dependencies (e.g. on remote servers, other people's
clients) then I don't think these should be run as part of the build.
This should be done in a controlled environment on a periodic basis,
and at least once with any release candidate.
> Any comments or suggestions?
>
Thanks
--
Jeremy
Re: WS interop/intergation/functional testing
Posted by James F Marino <ji...@gmail.com>.
On 4/25/06, ant elder <an...@gmail.com> wrote:
> There's been lots of debate on testing and no real agreement yet on what to
> do and this is blocking getting the WS interop testing setup which are part
> of the Wiki release plan. I'd like to propose the following and would
> appreciate any comments or suggestions. We need to move this along so I'll
> use lazy consensus, this is whats happening unless you provide a specific
> alternative.
>
> Create a new folder under testing called 'interop' . Interop may not be the
> best name, feel free to suggest alternatives.
>
> In testing/interop there will be two other folders, 'local', and 'remote'.
>
> testing/interop/remote will contain WS test clients that make WS invocations
> out to remote services on the Internet, so you'll need a network connection
> to run these and they'll probably be a little slow.
>
> testing/interop/local will include implementations of the WS services used
> by all the clients in the remote folder. It will also have clients to invoke
> those services but they'll just be extending the client code in the remote
> folder to override the endpoint used to be the local service but without
> requiring too much code duplication of the client code.
>
> Within the local and remote folders there will be separate projects for each
> set of tests, so projects for whitemesa, aspnetround3, amazon etc.
>
> These tests are using the actual SCA client APIs, they're not gong to be
> fudging things like the existing WS test in the tomcat integration tests.
> The testing/interop/local services need to be deployed and run in tomcat to
> work, so that will be done by the existing testing/tomcat stuff. I haven't
> quite though this part through yet, I guess that means having testing/tomcat
> get all the testing/interop/local sevices deployed and adding to
> testing/tomcat an interop test project which calls all the testcases in
> testing/interop/local. It doesn't seem perfect to require having
> testing/tomcat/interop as well as testing/interop, is there a better/easier
> way to do this?
Why can't "local" interop tests be done with integration testcases
without deploying to Tomcat, i.e. by piping requests in
programmatically to an Axis servlet and analyzing results in the same
manner, without the need for Tomcat or a fullblown Servlet container?
Also, I'm wondering what value remote testing provides other than
demonstration? Do the interop tests define messages that we can just
programmatically pipe in and out and just include "remote" testing for
demonstration purposes?
>
> So with that config you can run all the testing/interop/local tests to test
> out the Tuscany WS entryPoint and externalService function. Or you can run
> all the testing/interop/remote tests to verify interaction with real
> non-Tuscany systems.
>
> For now I wont even mention the question of when any of these tests should
> get run as part of a build process :-)
>
Definitely no in the remote case. I would also say no if the local
cases involves things such as deploying artifacts to a file system and
starting a server in another JVM.
> Any comments or suggestions?
>
> ...ant
>
>