How To Test Web Services?

[TheExcession]

Hi,

Hoping someone can offer some insight here.

Say, we develop a database system that stores a bunch of customer information, names, addresses, service profiles etc.

Then for the Operations team we expose this as a .NET Web Service so that the guys can modify the database using Web Forms hosted in a browser.

How do we automate testing this interface for its functional behaviour, e.g. Add a Customer, Delete a Customer, change Customer's password, change Customer's Service Profile.

I'm still trying to get my head around all this .NET Web Service XML/SOAP stuff.

We already have a scriptable test tool for testing RADIUS and SNMP intereactions, and I've ported this to .NET but I need to extend this to now perform on a Web Services interface.

The idea would be to get the tester to enter a customer into the database. Test that the Customer profile has been activated by simulating a call request using RADIUS.

Then go back in on the Web Services interface and bar the customer's profile, simulate another call and check that the request was rejected.

Anyone got any ideas or can point me towards some good info on this.

Many thanks
Ex

[Plotloss]

So you have created a publisher which accepts the SOAP, yes?

You now need to create a subscriber (client) to prepare the XML document to the schema that the publisher has been defined to.

[gopher]

If you have a copy of vs.net 2003 pro or above (I think - it may be available on lower editions) check out ACT - (under VS.Net features on the start menu) this will allow you to record a session as a vb or js script so you can copy and paste it, change parameters etc and re run.

Cheers

Paul

[Plotloss]

The other thing you should have as part of creating the publisher is a WSDL and an XSD

.NET has this thing called wsdl.exe import which will create you a class to the specification of the WSDL and the XSD

This can then be called to test your web services.

If you get massively stuck and have the XML document without the SOAP wrapper and the webservice is on the internet I have a testbench which will create a SOAP wrapper to spec, unfortunately its written using a proprietary toolkit so isnt portable.

[TheExcession]

Plotloss said:

So you have created a publisher which accepts the SOAP, yes? You now need to create a subscriber (client) to prepare the XML document to the schema that the publisher has been defined to.

Nope, haven't created anything yet, just that past experience has shown me that the testing phase at the end of the cycle if a fookin pain in the ass.

Previously we've always developed our systems in a disparate set of technologies, Orale, Java, Apache, JScript dah di dah di dah.

This time I'm trying to get everything under one umbrella that doesn't leave me having to write test tools and scripts for a month.

I've been looking at MS Visual Studio 2005 Team System
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/vstsinstallguide.asp

Seems like the dogs danglies - anyone using this?

cheers
Ex

[Plotloss]

Basically think of web services just like any other function call but rather than being an RPC its a document thats tunnelled through a firewall with a method attached.

The envelope defines the address and method, this is then opened and the payload (XML) is passed to a processor which reads it node by node (to a pre agreed schema) and calls a function which returns a result and the process happens in reverse.

I'll tell you now to save you headaches later, make every parameter an XSD:String and sort out the datatypes at the publisher end. This is because even with the will of the technical world IBM and MS cannot clearly define what a number actually is.

[Mark.S]

Time to explore nUnit! Good article for using it for web services here

[Don]

Plotloss said:

I'll tell you now to save you headaches later, make every parameter an XSD:String and sort out the datatypes at the publisher end. This is because even with the will of the technical world IBM and MS cannot clearly define what a number actually is.

Damn good advice. It was ever thus...