In web service rich systems you can leverage the interfaces that these services provide and test as much of the system as possible. Web Services give you a great opportunity to do quick regression and integration testing of business logic without going through a front end system or creating complicated test harnesses across your system. Automation at this level is extremely valuable to any deployment pipeline.
For this example we are going to use
this banking utility api from
http://www.ibanbic.be that provides several IBAN and BIC conversion facilities. The service uses the soap protocol.
To begin with we need to create a new class library project in visual studio with a references to NUnit. Download NUnit
here if you don't have it. You will need to add the following reference ..\ NUnit-2.5.10.11092\bin\net-2.0\framework\nunit.framework.dll. You may also need to add System.ServiceModel as well.
Once all the references are added we then need to create a c# proxy client class based on the contract (wsdl) of the target web service. We do this using ms svcutil, which you can read more about
here.
Once the proxy client class is created add it to the VS project. During the process of creating this proxy client class, an app.config file should have been created as well. Add this to the project.
ProjectName\Services\proxyClient.cs
Invoking the web service
If you don't know how the service works, use a tool like soapUI to interrogate the different requests and responses. This will allow you to become familiar with the data required to be sent with a request, and the expected response.
For this example we are going to invoke the service and use the calculateIBAN1 operation which takes two parameters
ISOCountry and
account to return an IBAN number.
The code is very simple. I've placed a method inside a class called converters.cs which sits inside a solution folder called modules.
namespace WebServiceAutomationSOAP.Modules
{
class Converters
{
public string CalculateIBAN(string isoCode, string account)
{
try
{
BANBICSoapClient client = new BANBICSoapClient("IBANBICSoap");
string iban = client.calculateIBAN1(isoCode, account);
return iban;
}
catch (Exception e)
{
return e.ToString();
}
}
}
}
We can now call this method and return either an iban number or an exception.
Setting up the test framework
As with many other examples on this blog, the test framework uses NUnit and separates out business logic from test logic using module classes for business, and test classes for tests. As we saw above we created a module class called converters.cs. Each module class has a corresponding test class.
Create a class called ConverterTests.cs and place it in a solution folder called Tests. Inside this class we will create two tests, one that tests for the correct IBAN creation, and another to check that the correct exception is thrown.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using NUnit.Framework;
namespace WebServiceAutomationSOAP
{
[TestFixture]
public class Class1
{
[SetUp]
public void SetUp()
{
// Do some set up configuration here
}
[Test]
public testCorrectIBANIsCreatedUsingCalculateIBAN1()
{
string expectedIBAN = "IBAN ES44 0000 0333 0000 0000 3434";
Modules.Converters converters = new Modules.Converters();
Assert.AreEqual(expectedIBAN, converters.GetIBAN("ES", "000003333434"));
}
[Test]
public testCorrectExceptionIsCreatedWhenIncorrectBankCodeIsUsedWithCalculateIBAN1()
{
string expectedException = "This is the expected exception";
Modules.Converters converters = new Modules.Converters();
Assert.AreEqual(
expectedException , converters.GetIBAN("ES", "cwsaSDFASD"));
}
[TearDown]
public void TearDown()
{
// Clean up here
}
}
}
Expanding the idea
Once you have this simple test framework in place you can begin to build a suite of tests around a web service very easily. To expand this further you can think about placing the creation of the web service client in the constructor of a base class that can then be inherited by all module classes.
You could also add data driving by using either a constants class, an application configuration file, or a library such as
FileHelpers to manage excel or text files.
Of course, soap is not the only webservice type out there. RESTful services have become much more widespread with google, yahoo, twitter adopting these over soap services. I will give some examples soon of how to automate these!
