On 4/25/06, ant elder <[EMAIL PROTECTED]> 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 > >
