May 5, 2016

Microsoft Faking Framework for Unit/Integration Testing

What is the Faking Framework?

The Microsoft Faking Framework is an isolation (mocking) framework that allows us to mock the static, sealed method without rewriting any implementation code. The mocking is primarily used in unit testing. An object under test may have dependencies on other (complex) objects; to resolve that dependency in unit testing, we need to mock. If we have a dependency on other components in a project, then we need to implement mocking for automated unit test cases. The benefits of MS fakes include easy-to-write unit tests and less refactoring time, although at the expense of maintaining tightly-coupled code.

Available frameworks for mocking

There are a lot of frameworks available for mocking, including:

  • MOQ
  • Rhino
  • Moles
  • Faking (new in MS VS 2013)

Comparison among MOQ, Moles, Rhino, and MS Faking frameworks

S. No. Feature MOQ Moles Rhino MS Faking Framework
1 Licensing Free Free (MS VS Gallery) Free Free (VS 2013 Ultimate and Premium)
2 Can Mock: Interface Yes Yes Yes Yes
3 Abstract Class Yes Yes Yes Yes
4 Event Yes Yes Yes Yes
5 Exception Yes Yes Yes Yes
6 Concrete class virtual methods/properties Yes Yes Yes Yes
7 Concrete non-virtual member No Yes No Yes
8 Static class No Yes No Yes
9 Sealed class No Yes No Yes
10 Protected virtual No Yes No Yes
11 Supports callback on mock method Yes Yes Yes Yes
12 Supports multi-threading exception No Yes Yes Yes
13 Supported version 3.5/4.0 2.0/3.5/4.0 1.1/2.0/3.0/3.5 4.5
14 Support Linq Yes Yes Yes Yes

Background of Faking Framework

The Fake framework in VS 2013 is the next generation of moles and stubs and will eventually replace the Moles feature.

A stub replaces a class with a small substitute that implements the same interface. To use stubs, we have to re-design our application so that each component depends only on interfaces, and not on other components. By "component" we mean a class or group of classes that are designed and updated together and typically contained in an assembly.

A shim modifies the compiled code of our application at run time so that instead of making a specified method call, it runs the shim code that our test provides. Shims can be used to replace calls to assemblies that we cannot modify, such .NET assemblies.

 Integrate VS 2013 with MS Fake Framework

The Fake framework has two components:

  1. Stubs
  2. Shims

When we are using a mock object or methods and using stubs, we need to design our class structure according to the stubs rule that each class should be inherited to interfaces.

Integration with Visual Studio

To start writing unit test cases using MS Fake, we need to add the Faking framework library.
Right click on Add reference of test project > click on browse tab > click on browse button > give that path to add faking DLL

"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies\Microsoft.QualityTools.Testing.Fakes.dll"

The integration of Fakes with Visual Studio 2013 is brilliant. To create a "fake" of an assembly, we need to right click on the references and click the option "Add Fake Assembly" in test project.


When we add a Fake assembly in our test project by right clicking on the reference assembly and clicking the "Add Fakes Assembly" option, Visual Studio adds the following files:

1. A new "Fakes" folder is created with a .fakes files created in it. For example, if we are creating fakes for "System.Configuration," a file called "System.Configuration.fakes" will be created.

2. A new "FakesAssemblies" folder is created with three files created:

  • originalAssembly.assemblyversion.Fakes.dll
  • originalAssembly.assemblyversion.Fakes.xml
  • originalAssembly.assembly.Fakes.fakesconfig

So, for the "System.Configuration" assembly, the files generated would be System.Configuration.,System.Configuration. and System.Configuration. 

Visual Studio also adds a reference to the generated assembly in the "FakesAssemblies" folder. The "FakesAssemblies" folder and all of the files in it are generated whenever the project is compiled. This is important because if we are adding fakes for an assembly for a changing component, the generation of the "FakesAssemblies" will ensure that all changes are reflected in the generated assembly.

After adding a successful faking DLL(s) system, we will add one more DLL named mscorlib.

Note: The mscorlib. assembly contains a special type called Shims. Shims are a strongly typed wrapper that allows developers to replace .NET types with delegates.

Structure of a Unit Test Project

The structure of a unit test screen looks like the screen shown below. The left part of the screen is a test execution result. The right part of the screen is a structure of the test project. The center part of the screen is the actual unit test case.

To execute the test cases, right click on the test method and choose "Run test" or go to Test > Run > All test.


Structure of Unit Test Case

public class ThingTest
        // Setup

        // Exercise

        // Verify

        // Teardown

    public void TestSomething()

Create Bootstrap


Create setup (all required DB objects) to execute the test case.


How to use Shims


Attributes of unit test method

MSTest Attribute Purpose
[TestMethod] Identifies an individual unit test
[TestClass] Identifies a group of unit tests, all tests, and initializations/clean ups that must appear after this declaration
[ClassInitialize] Identifies a method that should be called a single time prior to executing any test in the test class/test fixture
[ClassCleanup] Identifies a method to be called a single time following the execution of the last test in a test class/test fixture
[TestInitialize] Identifies a method to be executed each time after a test method/test has been executed
[TestCleanUp] Identifies a method to be executed each time after a test method/test has been executed
[AssemblyInitialize] Identifies a method to be called a single time before running any tests in a test assembly
[AssemblyCleanUp] Identifies a method to be called a single time after running all tests in a test assembly
[Description] Description of the test method
[TestCategory] Defines the category of the test method. This can be positive or negative
[DataSource] Defines the data source of a test method by which the method gets the data and executes the logic. It can be XML, CSV, or Database
[DeploymentItem] Specifies a file or directory that should be deployed along with the assemblies before running a test. Attach this attribute to a test class or method. We can use multiple instances

Modifications Required to Project

If we mock the object or class by using "Shims" then there is no need to change anything in the solution. However, when we use "Stubs," we then have to re-design the structure of the solution because it will inherit all of the classes from the interface.

Challenges/Issues and possible workarounds

When we add the Fake assembly of main project as an EXE/DLL (which we want to write the unit test case), the "Project.fakes" file is added from the Fakes folder into test project. It may be possible that this will throw an error - if an error is thrown by the system during a build, the cause of the issue could be that test project fakes give a compilation error. The exact error is given below:

"Could not resolve this reference. Could not locate the assembly 'System.Configuration.'. Check to make sure the assembly exists on disk." The error would go away if I added the FakesAssemblies folder in Source control. After a detailed analysis, we found that the reason the error happened was because the “Build action” for the ".fakes" file added to the project was not set correctly. These files should have the build action set to "Fakes" instead of "None."


Before the set build action was "Fakes," it was:



MS Fakes work only with the Ultimate or Premium edition. I have installed the professional edition and found it does not work.

Open AssemblyInfo.cs of the main project and add [assembly: InternalsVisibleTo("UnitTestProject")] as shown in the screen below.

When we play with an external data source like XML to execute our test case, we need to add the reference of "System.Data" by right clicking on Reference > Add reference, otherwise we can not read the data from the XML file.

After the code was written to get the test values from external data source, I could not get a result like screenshot shown below.

The following are the common issues that you may encounter along with their solutions.

Issue: The unit test adapter failed to connect to the data source or read the data.


Solution: Go to the Solution Explorer, add a new item into solution, select "Test Settings" from the left menu, and then add a new test setting.


In the "Test Settings" window, select "Deployment" from the left menu, then check the "Enable Deployment" check-box and click on apply.


If the problem still persists, go to Solution Explorer, locate the test data XML file and then open the file properties. Make sure the "Copy to Output Directory" property is NOT set to "Do not copy" - make it either "Copy always" or "Copy if newer" like the screen shown below.


After doing all of the above steps, it should work like so:



Unit testing is a major component of every project. The early feedback received from our tests help us feel confident that we didn’t introduce new bugs and that we gave actual working code to QA. The Faking framework helps us to mock the dependent complex module like email server and database layer. We don't need to implement a dependency injection and we don't need to create a fake by inheritance. Every faked instance looks and feels like an instance of the faked type. After comparing all of the other mocking frameworks available in the market, the MS Faking framework gave us more features than the others. Therefore, we highly recommended using the MS Fakes with your projects to have a better delivery of the code.