Hello, Our development team likes to make a lot of changes to WSDL and there is quite a break down of communication between QA and development. I dont typically discover the changes till some scripts start breaking and I eventually figure out that the WSDL has been updated.
Is it possible that when I do 'Update Definition', I can get a log of changes/updates that occurred on that WSDL. This would be really helpful since I can relay this information to many concerned people in the team.
we have been discussing this lately, the problem is that "diffing" between schemas can be extremely difficult since a change can often interprated in different ways, for example if an element is renamed is that a delete/insert or a rename? What if a new element with the same name has been created at the same time.. would that be a move? etc..
One initial solution would be to add "refactoring" support to the existing interface-viewer, for example right-click on a complex-type and select rename would propagate that change to all depending requests.. But then again, this would require you to know the changes to the WSDL your development team made and enter them "manually" instead of just using "Update Definition"..
The latter solution is not that difficult to implement, so it could be our initial "WSDL Refactoring" support.. the diff would come later..
Ole, Not sure if this is by design or a bug. When I do an update definition, seems like the definition gets updated but when I look at the actual method in the 'Interface', it still has the old definition. So after I do a 'update definition', I go to each of the methods in the interface, and do a 'recreate a default request..' and then I can see the updated definition.
I understand why its a tricky situation to update the actual test cases if the WSDL changes, but I would assume that update definition should update the method definitions in the 'Interface'
the method definitions are just sample requests generated from a/the previous interface, so updating them would first require an analysis of the new WSDL to "understand" what has changed to be able to update the sample requests accordingly.. that's the tricky part.. 🙂
Since they are sample requests based on the WSDL specified for the interface, i think its only logical that if you update the WSDL then these sample method definitions should also be updated. I guess as a solution to this; after the user updates the definition, there should be some prompt that allows the user to also update/recreate all the methods for that interface. What do yo think ?
This is just an idea/suggestion based on my understand of the problem with refactoring. Ideally it would be nice to have a list of changes that development does but in reality this does not really happen. Though not a perfect solution would it make sense to do the following after the WSDL has changed.
1. user updates the definition. 2. user selects to force new method definition to all instances of that method across all test cases in the project.
This can drastically change the project and will likely cause many property transfer failures. However, I think those are easy to fix/rescript. I would personally first create a backup of my project before doing this since its such a big change in the project file.
This approach fixes the major headache that I (QA) have - I am issuing request to my web service using XML request structure that is no longer supported because the WSDL has changed.
I've been thinking more about this and may have come up with a solution that is not that difficult to implement.. I wonder if you could send me a set of WSDLs that illustrate the kinds of changes you are experiencing from you development team (ie "before and after" WSDLs).. alternatively if you could describe the changes (ie namespace renames, element renames, attribute->element, etc..) you are most commonly encountering..