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
