Introduction
Web services are a part of many applications today. Typically, client applications access web services through proxy classes, which are either generated by a tool or written by hand. Your client application communicates to those web services through those proxy classes.
However, many applications that communicate with web services end up tightly coupling themselves to those web services, which makes the application’s code very difficult to unit test. This article proposes a technique that can be used to avoid that tight coupling and make writing your unit tests correctly easy to accomplish.
All the code in this article is supposed to be C#. It has been written by hand, but I believe the code should be accurate enough for the reader to gain an understanding of what the code is supposed to do.
This post was inspired by a question on stackoverflow.com.
Scenario
You’re developing a client application which uses a single third party web service to authenticate users and track statistics on your application’s usage. You’ve already generated a proxy class that you can use to communicate with that web service using a tool.
Your code looks a little like this:
-
class UserServiceProxy
-
{
-
// Auto-generated proxy class.
-
public Boolean Authenticate(String user, String password);
-
}
-
-
class UserManager
-
{
-
public String CurrentUser
-
{
-
get; private set;
-
}
-
-
public Boolean Login(String user String password)
-
{
-
var proxy = new UserServiceProxy();
-
-
if (proxy.Authenticate(user, password))
-
{
-
CurrentUser = user;
-
return true;
-
}
-
else
-
{
-
CurrentUser = null;
-
return false;
-
}
-
}
-
}
Fair enough – it looks like if the service says the user’s authenticated, we store the user’s name. If not, we reset the user’s name. Let’s confirm that with some unit tests…
Hang on a minute. If you run a unit test on that code, it’s going to call into the third party web service. If we use a valid user’s credentials, we’ll end up screwing with the statistics that the service is recording.
However, we can just create special test users and log in with those credentials, right? Well, not if you want deterministic unit tests. What if the web service goes down, or screws up a response? Random test failures are a major (and I say this from experience) pain in the ass.
Where do we go from here?
Mocking
We need to mock the web service. We’ll create a class that pretends to be the proxy to the web service, and we can then control the responses that class sends back to our UserManager instance. Because we control exactly what gets sent back from this ‘mock proxy’ we can simulate authentication success, failure, and even exceptions.
But hang on, our design doesn’t yet support mocking:
- There is no way to change the object that provides authentication in the UserManager class.
- The proxy is not coded to implement an interface.
The first point is the most important. We’ve tightly coupled UserManager with UserServiceProxy. We can however, make the following improvement.
-
class UserManager
-
{
-
// Other code omitted for clarity.
-
-
private readonly UserServiceProxy proxy;
-
-
public UserManager(UserServiceProxy proxy)
-
{
-
if (proxy == null)
-
{
-
throw new ArgumentNullException("proxy");
-
}
-
-
this.proxy = proxy;
-
}
-
-
public Boolean Login(String user, String password)
-
{
-
if (proxy.Authenticate(user, password))
-
{
-
CurrentUser = user;
-
return true;
-
}
-
else
-
{
-
CurrentUser = null;
-
return false;
-
}
-
}
-
}
Now we supply the proxy we want to use for authentication in the UserManager class’s constructor.
The second point, that the proxy class isn’t coded to an interface may be slightly less important depending upon your circumstances. If all the methods you want to mock are virtual, then fine – you can derive from the proxy class and override those methods. However, even then you still may have issues. Our mock object doesn’t need anything that’s in UserServiceProxy, and to be honest, we’ve not really got a clue what UserServiceProxy does on construction – it could be contacting the web service to do some initialization for all we know.
It would be much cleaner if we could write our mock class to an interface. However, UserServiceProxy doesn’t implement an interface…
The Adapter Pattern
We can’t touch UserServiceProxy’s code – it’s generated by a tool. But we can use the adapter pattern to create a class which enables UserServiceProxy to conform to an interface. We can then pass an instance of that interface into UserManager’s constructor.
Let’s start with the interface:
-
interface IUserAuthenticationProvider
-
{
-
Boolean Authenticate(String user, String password);
-
}
Now, we need a class which implements that interface, but uses ClientServiceProxy for its implementation:
-
class ClientServiceProxyAdapter :
-
ClientServiceProxy, IUserAuthenticationProvider
-
{
-
#region IUserAuthenticationProvider Implementation
-
-
public IUserAuthenticationProvider.Authenticate(String user, String password)
-
{
-
return base.Authenticate(user, password);
-
}
-
-
#endregion
-
}
Now we update our UserManager class to accept instances of IUserAuthenticationProvider:
-
class UserManager
-
{
-
// Other code omitted for clarity.
-
-
private readonly IUserAuthenticationProvider proxy;
-
-
public UserManager(IUserAuthenticationProvider proxy)
-
{
-
// Constructor code same as previous example.
-
}
-
}
Cool. Now when we create our UserManager, we create an instance of ClientServiceProxyAdapter and pass it in to UserManager’s constructor. If we’re unit testing, we’ll pass in an instance of a mock class that implements IUserAuthenticationProvider. Lets create out mock class now:
-
class MockUserAuthenticationProvider : IUserAuthenticationProvider
-
{
-
Func<String, String, Boolean> AuthenticateImpl { get; set; }
-
-
public Boolean IUserAuthenticationProvider.Authenticate(
-
String user, String password)
-
{
-
if (AuthenticateImpl == null)
-
{
-
throw new InvalidOperationException(
-
"Cannot call Authenticate when AuthenticateImpl is null");
-
}
-
-
return AuthenticateImpl(user, password);
-
}
-
}
Great. We now have a mock class where we provide the implementation of Authenticate dynamically. We can now write some tests for UserManager.Login.
(Assume that the Assert class is part of your preferred unit testing framework, and provides methods used to pass or fail tests).
-
class UserManagerTestFixture
-
{
-
public void TestLoginSuccess()
-
{
-
var mock = new MockUserAuthenticationProvider
-
{
-
AuthenticateImpl = (u, p) => true
-
};
-
var um = new UserManager(mock);
-
Assert.IsTrue(um.Login("User", "Password"));
-
Assert.AreEqual("User", um.CurrentUser);
-
}
-
-
public void TestLoginFail()
-
{
-
var mock = new MockUserAuthenticationProvider
-
{
-
AuthenticateImpl = (u, p) => false
-
};
-
var um = new UserManager(mock);
-
Assert.IsFalse(um.Login("User", "Password"));
-
Assert.IsNull(um.CurrentUser);
-
}
-
-
// Test fails for now, we've not specified what happens when
-
// we get an exception from our IUserAuthenticationProvider.
-
public void TestLoginException()
-
{
-
var mock = new MockUserAuthenticationProvider
-
{
-
AuthenticateImpl = (u, p) => throw new NotWorkingException()
-
};
-
var um = new UserManager(mock);
-
um.Login("User", "Password");
-
}
-
}
There. We’ve now got good test coverage of UserManager, and can see that it’s doing its job with regards to the CurrentUser property for two cases. We can now specify and fix up the third case, get this stuff reviewed by a colleague and get it checked in, with the confidence of knowing that UserManager will interact correctly with those third party web services.
Conclusion
Unit testing is an extremely important part of software development today. Writing code that is unit testable can be a challenge, but unit testable code is often extremely versatile, modular and more likely to be correct. This article has shown how to decouple an application and any web services it might access, and how to mock a web service so that code which interacts with that web service can be properly unit tested.
