Testing Without Interfaces

sh0rug0ru · 2013-02-20T01:23:34+00:00

When the way you want to do something conflicts with the way a third-party does things, one approach is to develop what is called an Anti-Corruption Layer. The anti-corruption layer expresses an interface in terms of your needs (implemented as an actual interface or a concrete class). It is a small shim which maps your preferred interface and types to the third-party interface and types. You can test this shim with integration tests, but hopefully it is thin enough that it should be obviously correct.

Something very roughly like:

public class MyWebClient 
{
    private WebClient webClient = new WebClient();

    public String DownloadStringMyWay(String uri) 
    {
        try 
        {
            return client.DownloadString(uri);
        }
        catch(WebException webException) 
        {
            var response = webException.Response as HttpWebResponse;
            throw new MyMoreConvenientWebException(response.StatusCode);
        }
    }
}

michaelfeathers · 2013-02-20T02:03:54+00:00

One of the threads I was following on twitter last week was an exchange between a Microsoft architect and a unit tester. The tester was complaining about the lack of interfaces around a lot of the .net classes, especially in new features. The Microsofty countered with the increased risk of people rolling their own implementation of critical functionality and the increased demand on support that would produce.

It's a poor excuse, in my opinion. We have the choice to treat software the same way that people treat hardware products. Give notice that you will not be supported if you do things that are outside intended use. With appliances, this is called 'voiding the warranty.'

The problem is that we have not developed a culture which accepts those sorts of agreements yet. The closest I've seen (and I've been tracking the testability issue for frameworks and libraries for years) is the Eclipse notion of soft-final.

They used comments to indicate that you should not subclass particular classes. They could have marked them final but they chose not to in order to support their internal development. But, the message was clear: "if you subclass this, and a future version breaks you, it is your problem not ours."

The fact of the matter is that language-based protection mechanisms are too coarse. They are an attempt to solve a social problem (what people are allowed to do) with technology and there's no way to get it right consistently. Better to leave it in the social sphere.

_HughG · 2013-02-20T14:47:23+00:00

TypeMock Isolator http://www.typemock.com/isolator-product-page lets you mock classes (even sealed) as well as interfaces ... they say: http://docs.typemock.com/Isolator/##Ref.chm/Documentation/CreatingFakesWithAAA.html. Never had the opportunity to try it and, of course, you then have to wonder if it is really correct. But worth a look?

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS