Web services for automation testing

[ravkrr]

Hi guys,

I am quite new to Spring-WS and I need some advice.
We currently have an internal tool for automation testing, but it is not easy to maintain and I now need to replace it to facilitate automation testing by testers.

I need to expose a service module as a web service and prove that we can achieve automation testing through web services. The module has a number of service classes and has already been created. The output also contains a number of domain objects, which are quite huge as well.

I have started to read through http://static.springsource.org/sprin.../tutorial.html and I am still setting up a sample project, to prove that it can be done.

Would you please let me know how you would do it?

I am also unsure of the advantage behind contract first, whether you define the contract before or after does not matter, right? Because when it changes you still have to notify your client and they have to rebuild.
Its actually one of the things I need to get right, i.e, after a change in interface is done there needs to be little maintenance done to be able to go ahead with integration testing, for both Dev and Test.


Thanks for answering
Kris

[Marten Deinum]

I think you miss the point of contract first... Contract first (or interface first if you would look at classes) makes you think about your interface and that your contract is basically independ from your implementation.

You should prevent the xsd/wsdl creation by using generation tools based on your interfaces/code as that (in a lot of cases) breaks the contract each time you modify/refactor classes.

[ravkrr]

Hi Maarten,

let me try to get this right, in both cases you will end up with a WSDL and XSD(which represents the contract). If it changes you will end up having to notify the clients so that they can now use the new contract, right?

Can you please also provide some insight on how you would proceed in my case of automation testing

Thanks
Kris

[Marten Deinum]

The automated generation approach is far more brittle then defining the contract first...If you need to change your contract in general you either haven't thought it through or have a changed functionality... You don't want your contract to break simply because you did some refactoring/cleaning up would you...

[ravkrr]

So that I understand the scope of work that will be required each time there will be a change, such as 2 new fields need to be surfaced in one of the domain objects, are the steps required below correct

Dev Side
1.) modify the xsd, add those 2 new fields and publish a new version
2.) modify the WSDL to point to the new XSD
3.) rebuild the web service module
4.) deploy the web service server side

Test side
1.) use the new WSDL
2.) modify the tests files concerned with the change

Thanks
Kris