IronCow and the design for testability
IronCow is a library that wraps the Remember The Milk (RTM) web services. The “upper layer” of the IronCow API is an object model that stays in sync with the server and is designed with data binding in mind.
Of course, one of the things that went into IronCow’s design was testability. IronCow ships with a suite of unit tests that, well, test that the API is working fine. However, there’s another testability aspect: how the clients of your API are going to test their stuff. These are 2 different things:
- Within IronCow, “design for testability” means I have to be able to mock the underlying client that communicates with the RTM REST API. Then, I can manipulate my objects and check that the correct requests are sent, and that those objects behave correctly according to the responses I give.
- From the point of view of a client, though, “design for testability” means they have to be able to make IronCow behave a certain way, and test that the rest of their application behave accordingly.
Therefore, right now, to use IronCow in a test environment, you can disable the “syncing” behaviour like this:
Rtm rtm = new Rtm(); // You can also pass in your apiKey and // sharedSecret here but it doesn’t matter. rtm.DisabledSyncing(); // From now on, there’s no requests being sent.When syncing is disabled, the IronCow object model just acts like a “dumb” object tree. Setting the name of a task or adding a new contact won’t trigger a request to RTM. Instead, it will just modify the objects locally, as if it was just a classic simple in-memory object model.
Note that you can’t reenable syncing.
The problem with this is that although the complexity of the public interface stays the same, the complexity of the internal code increases. I find it doesn’t increase nearly as much as when I tried to hide everything behind interfaces though. The other bigger problem is that it’s more complicated for clients to do behavioural testing. For example, if they want to test what happens in their application when a certain action makes IronCow throw an exception, there’s nothing to help them do that… In that case, they have to mock the IRestClient class, and use it with their Rtm instance. There are helper classes and methods to build RTM XML responses, but it’s not what you would call super user friendly (check the IronCow.UnitTests assembly source code for examples of how to use it).
So is this fine? No? Should I bite the bullet, add interfaces, and make this simple API be 3 times bigger and more complex? Is there a third option?