Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have started a project on CodePlex for a WebDAV server implementation for .NET, so that I can host a WebDAV server in my own programs. This is both a learning/research project (WebDAV + server portion) as well as a project I think I can have much fun with, both in terms of making it and using it.

However, I see a need to do mocking of types here in order to unit-testing properly.

For instance, I will be relying on HttpListener for the web server portion of the WebDAV server, and since this type has no interface, and is sealed, I cannot easily make mocks or stubs out of it.

Unless I use something like TypeMock.

So if I used TypeMock in the unit-test projects on this library, how bad would this be for potential users?

The projects are made in C# 3.5 for .NET 3.5 and 4.0, and the project files was created with Visual Studio 2010 Professional.

The actual class libraries you would end up referencing in your software would of course not be encumbered with anything remotely like this, only the unit-test libraries.

What's your thoughts on this?

As an example, I have in my old code-base, which is private, the ability to just initiate a WebDAV server with just this:

var server = new WebDAVServer();

This constructs, and owns, a HttpListener instance internally, and I would like to verify through unit-tests that if I dispose of this server object, the internal listener is disposed of. If, on the other hand, I use the overload where I hand it a listener object, this object should not be disposed of.

Short of exposing the internal listener object to the outside world, something I'm a bit loath to do, how can I in a good way ensure that the object was disposed of?

With TypeMock I can mock away parts of this object even though it isn't accessed through interfaces.

The alternative would be for me to wrap everything in wrapper classes, where I have complete control.

share|improve this question

3 Answers 3

up vote 3 down vote accepted

How about using the Adapter pattern, perhaps in combination with dependency injection?

You could provide an interface/wrapper for HttpListener and write your code against that interface. You can then mock that interface out in your tests with an OSS mocking framework or by writing a manual mock implementation.

share|improve this answer
    
That means exposing the internal listener. If I call the constructor that doesn't take any parameters, I wouldn't have access to the listener object, wrapped or not, and wouldn't know whether it was correctly disposed of or not. Perhaps I just need to change how I think about this. –  Lasse V. Karlsen Feb 12 '11 at 18:39
    
@Lasse: Would an internal constructor that's accessible to the test assembly work? Or your listener could be "protected" and your mock server implementation could subclass the actual implementation and check its status? –  Anna Lear Feb 12 '11 at 18:43
    
I've decided against the parameterless constructor and to go with the adapter pattern. –  Lasse V. Karlsen Feb 12 '11 at 18:46
    

For a custom HTTP thing I ended by using C# Webserver instead of the HttpListener. This project is amazing and you should have a look at it.

And of course there is the IHttpListener interface.

share|improve this answer

It's not a problem at all. In fact, I believe the Prism libraries and guidance (provided by MSFT) do exactly this with a different test framework. In order to compile the unit test projects and run the tests, you have to download the test framework separately and drop a couple of DLLs into certain folders. The installation instructions include explanation about how to do it.

share|improve this answer
    
In the TypeMock case, the instructions would start out with "First purchase a license for TypeMock Isolator". –  Lasse V. Karlsen Feb 12 '11 at 21:07
    
I just learned that there is an open source license for TypeMock Isolator. I've fired away an email to TypeMock support asking if there are any other restrictions in that license beyond the limitation that it can only be used to work on open source projects. Hopefully the answer is "no" :) –  Lasse V. Karlsen Feb 12 '11 at 21:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.