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.