Fake Assemblies show warnings when generating shims for Interface and stubs for sealed types

Question

I have a build configured with CI post which some tests are run. Although the tests run successfully, the build shows warnings:

: Cannot generate stub for StructuremapMvc: type is sealed. : Cannot generate shim for IUnitOfWork: type is an interface. : Cannot generate shim for Repository.IRepository`1: type is an interface.

and so on.

I am using a generic repository pattern along with Unit Of Work. I have added Fake Assemblies for my MVC WebApi project (which leverages Dependency Injection using StructureMap) and Data project which contains my Repositories and UnitOfWork. I have explored this error and seem somewhat convinced that this maybe due to limitations of the Fake Assemblies, but I need to be absolutely sure that I am not doing anything wrong

Answer 1

The way I got rid of these warnings was to only create the shims which are needed. I added the following to the fakes config file.

  <ShimGeneration>
    <Clear/>
    <Add FullName="ATypeToShim!"/>
    <Add FullName="AnotherTypeToShim!"/>
  </ShimGeneration>

The ! at the end of the filter makes it a precise case-sensitive match.

For stubs, I only ever stub interfaces so its easy:

<StubGeneration>
  <Clear />
  <Add Interfaces ="true"/>
</StubGeneration>

There are more details here: http://msdn.microsoft.com/en-us/library/hh708916.aspx#bkmk_type_filtering

Answer 2

It's not really a limitation of Fakes, but neither is it really an error. What you need to know is what stubs and shims are.

Stubs are simple: they're a class which implements or extends some class, overriding every method with a delegate property and a flag determining whether it should call the base class afterward (note: that flag is for the entire stub, not per method). You use them for injecting dependencies, since they allow you to locate all your logic in lambdas in code, rather than in a generated class somewhere. Because they extend non-interfaces, sealed classes cannot be stubbed.

Shims are more complicated, because they apply to any instance of a specified type. Not sure exactly how this is done, but what matters to you is that since an interface cannot have an instance, it cannot have a shim. That's fine, since that's where you should be using a stub. They are dangerous, because with a shim, you override the result of a function within the entire shimscontext, and are almost exclusively when something breaks that you don't have access to - something that would be better injected.

So I wouldn't worry about the warnings. They aren't really about anything important, just making sure you know what's happening.