Unit testing a third party API with sealed concrete classes

just started TDD and all was going well until I hit this brick wall.

I am writing a facade around a third party API. The API is quite nice in that everything is accessed via interfaces, so is easily mockable when testing my facade.

The whole API is accessed via a root interface and there is a deep hierarchy of interfaces you can drill down into from this. My facade takes this root interface in its constructor in standard IoC practice.

TDD was going fine, with the slight pain that mocking was getting a bit complex when using deep interfaces, since I have to mock the entire interface tree. No biggie though, I just maintained a helper function that built the mock. It does make me wonder if I'm using the right approach though.

Anyway, halfway down the tree I have now suddenly hit a sealed concrete type, with no public constructor, so I have no way of mocking it. This is causing my tests to fail since the mocked API always returns null for this member.

The only way I can see around this is to create my own interface for this type, and have a virtual method on my facade for accessing it. However, this seems messy to me since I have no way of enforcing access to the type through this method, and it will be easy to forget. eg, it's natural to use:

ConcreteType c = SomeInterface.ConcreteMember;

instead of:

IConcreteType c = GetConcreteMember(SomeInterface);

Forgetting this would cause tests to fail.

Am I missing something fundamental? As I said I am very ne开发者_如何学Gow to unit testing.

ps. I am using Moq.

Use moles. By using this, you can create mocks for any sealed type (myself, I recently used it to provide mocks from the System.Web.HttpContext.Current property).

If you look at the documentation in the download (Microsoft Moles Reference Manual.docx), this should give you enough information to get you started.