Disable Entity Framework Code First Initialization Logic

When you use the Entity Framework Code First approach to build your database, EF’s default behavior is to verify if a database exists when the application runs the first time. In case it does not exist, EF creates it.

There might exist some situations when there is no need to run this initialization logic, e.g. when you run unit tests on an existing database.

Disabling the initialization for a given context type is really simple. This call will do the job:

System.Data.Entity.Database.SetInitializer<TContext>(null);

I found a sample on Stack Overflow where a custom System.Data.Entity.IDatabaseInitializer<TContext> was implemented, having an empty InitializeDatabase method. But why create and maintain a class when we can get the same result for free.

Setting the initializer to null should be performed before the database is accessed the first time by the context type. I prefer to put this into the initialization method of my application or inside of the TestInitialize method of my unit test classes. Putting this code into the ctor of the DbContext class will lead to an unneeded number of calls every time an instance of the context class is created.

And because I forgot to do so, an additional hint concerning the unit tests: It is not sufficient to disable the initialization logic for the DbContext type defined / used in the test project. Also, the initializer of the DbContext type used by the application classes, defined in the application project, has to be set to null.

Links

Understanding Database Initializers in Entity Framework Code First

Use Publicize.exe to Create Private Accessors for Visual Studio 2012+

Preface

Starting with Visual Studio 2012, private accessors cannot be created any more by the IDE. The post Home-made Private Accessor for Visual Studio 2012+ presents an approach on how to create private accessors using the class Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject.

Axel Mayer noted in the MSDN forums post How to create private accessors in VS 2012 that one can use the command line tool publicize.exe to create private accessors too.

Usage Of Publicize.exe

The usage of publicize.exe is quite simple. Open a command prompt, or a “VS2013 x86 Native Tools Command Prompt” to have the search path already set up, and run publicize.

In case you do not have the path set up correctly, the tool can be found at %Program Files (x86)%\Microsoft Visual Studio 11.0\Common7\IDE for Visual Studio 2012 or %Program Files (x86)%\Microsoft Visual Studio 12.0\Common7\IDE for VS 2013. At least, the tool is located there for the Ultimate edition of Visual Studio. I can’t tell which other editions contain it. Just have a look.

For a complete reference please refer to Using Publicize to Create a Private Accessor.

The usage in short: publicize.exe [options] input-assembly

The created assembly needs to be referenced by the test project. Of course, the source assembly – the assembly containing the classes to be tested – has to be referenced by the test project too.

publicize.exe creates classes named NameOfTheSourceClass_Accessor. In case the class to be tested is called MyClass, the accessor is named MyClass_Accessor.

publicize did work well for .NET 4.0 and .NET 4.5 assemblies in my tests. It also covered async and static methods.

Limitations

The docs mention that publicize does not support delegates or events.

From my tests I can add another limitation: publicize does not support Windows Store app assemblies (or I was not able to use it correctly). Running it against such an assembly I received these error messages (and a few more of the same type):

Cannot resolve dependency to Windows Runtime type ‘Windows.UI.Xaml.Application’. When using the ReflectionOnly APIs, dependent Windows Runtime assemblies must be resolved on demand through the ReflectionOnlyNamespaceResolve event.

Cannot resolve dependency to assembly ‘System.Runtime, Version=4.0.10.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.

Maybe you can give a hint on how this can be resolved. If so, please add a comment below. Thanks!

Resumé

As long as I don’t need accessors for Windows Store app assemblies, the usage of publicize.exe is my preferred way to generate private accessors.

In case publicize.exe does not support the source assembly type, I will created the private accessor myself as described by Home-made Private Accessor for Visual Studio 2012+.

Links

Home-made Private Accessor for Visual Studio 2012+

How to create private accessors in VS 2012

publicize.exe documentation

Home-made Private Accessor for Visual Studio 2012+

Why Home-made?

Short answer: Starting with Visual Studio 2012, private accessors cannot be created any more by the IDE.

It seems that this does not bother too many people. The ‘Bring Back Private Accessor’ suggestion on UserVoice has not found any supporters right now.

Nevertheless, I still need access to private members of classes for testing purposes. And I do not want to declare them as internal because these members should not be (mis)used from within the same assembly.

Update 2013-11-09

Axel Mayer noted in the MSDN forums post How to create private accessors in VS 2012 that one can use the command line tool publicize.exe to create private accessors too. See Use Publicize.exe to Create Private Accessors for Visual Studio 2012+ for a detailed description.

The Goals

Just a few things:

  • Type safety
  • Protect from typos
  • Easy to handle when rename is required
  • Encapsulate / hide the use of PrivateObject

Use of PrivateObject

Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject is the base class to build up our own private accessor infrastructure. Well, infrastructure is such a big word. As you will see later, this infrastructure is really lightweight.

The direct use of PrivateObject has some disadvantages. You always have to use strings as parameters to invoke a method or get / set the value of a property. So there is a good chance the call of a method fails because I mistyped the method name. Some casting issues come up too. And using async / await in .NET 4.5, the direct use of PrivateObject.Invoke does not look really funny.

The direct use of PrivateObject looks like this

// Create an instance of the class to be tested.
ClassToBeTested instance = new ClassToBeTested ();

// Create a PrivateObject to access private methods of instance.
PrivateObject privateObject = new PrivateObject(instance);

// Create parameter values
object[] args = new object[] { "SomeValue" };

// Call the method to be tested via reflection, 
// and pass the parameter, and cast the result
int result = (int) privateObject.Invoke("PrivateMethod", args);

// Do some validation stuff

Create an Accessor Class

The first step to get away from this unpleasant and code inflating use of PrivateObject is to create an accessor class inside the unit test assembly.

This accessor class will hide the usage of PrivateObject. It gives type safety and helps to avoid typos on method- and property names. In case a member of the tested class is renamed, there is one single place to change in the test assembly. All other changes in the unit test can be done by Visual Studio renaming support.

A short version of the accessor to ClassToBeTested might look like this:

internal ClassToBeTestedAccessor
{
  private PrivateObject PrivateObject { get; set; }

  internal ClassToBeTestedAccessor()
  {
    PrivateObject = new PrivateObject(new ClassToBeTested());
  }

  internal int PrivateMethod
    (
    string parameter
    )
  {
    return ((int) PrivateObject
      .Invoke("PrivateMethod", new object[] { parameter }));
  }
}

And the test method using the accessor changes to this:

// Create an instance of the accessor.
ClassToBeTestedAccessor accessor = new ClassToBeTestedAccessor ();

// Call the method to be tested
int result = accessor.PrivateMethod("SomeValue");

// Do some validation stuff

Now the test method itself already looks the way I like it.

Make Accessor Reusable

Let’s assume there is the need for more than one accessor class in the test assembly. Then it might make sense to put some functionality into a base class for reuse purposes.

The base class should keep the instance of the tested class and the PrivateObject to access it. This means it have to be generic to get a type safe implementation.

This will be the starting point:

internal abstract class PrivateAccessorBase<T>
{
  private PrivateObject PrivateObject { get; set; }

  public T TestInstance 
    { get { return ((T)PrivateObject.Target); } }

  internal PrivateAccessorBase
      (
      T instance
      )
    {
      PrivateObject = new PrivateObject(instance);
    }
}

Please notice the public property TestInstance. This proporty gives access to the instance that is encapsulated by the private accessor. In case the unit test method needs to access public members of the tested class too, use this proporty.

What is common in my unit tests is to get or set the value of a property and to call a method. Therefore, the base class should offer the ability to do that.

Property Access

To get a property value, one might implement a method like this:

protected TReturnValue GetPropertyValue<TReturnValue>
  (
    string propertyName
  )
{
  return ((TReturnValue)PrivateObject
    .GetProperty(propertyName, null));
}

But this implementation still requires to pass the name of the property as a string. This can be avoided by using the call stack (in case you are using .NET 4.5 or higher, please have a look below to avoid StackFrame usage):

protected TReturnValue GetPropertyValue<TReturnValue>()
{
  // Need to remove the "get_" prefix from the caller's name
  string propertyName 
    = new StackFrame(1, true).GetMethod().Name
      .Replace("get_", String.Empty);

  return ((TReturnValue)PrivateObject
    .GetProperty(propertyName, null));
}

Setting a property value looks quite similar:

protected void SetPropertyValue
  (
  object value
  )
{
  // Need to remove the "set_" prefix from the caller's name
  string propertyName 
    = new StackFrame(1, true).GetMethod().Name
      .Replace("set_", String.Empty);

  PrivateObject.SetProperty(propertyName, value, new object[] { });
}

Having this base class, we can implement the ClassToBeTestedAccessor like this:

internal ClassToBeTestedAccessor
  : PrivateAccessorBase<ClassToBeTested>
{
  internal ClassToBeTestedAccessor ()
    : base(new ClassToBeTested())
  {
  }

  internal int PrivateProperty
  {
    get { return (GetPropertyValue<int>()); }
    set { SetPropertyValue(value); }
  }
}

The usage of the property by the test class does not differ from the usage of ‘normal’ properties:

// Create an instance of the accessor.
ClassToBeTestedAccessor accessor = new ClassToBeTestedAccessor ();

// Set the value
accessor.PrivateProperty = 231;

Debug.WriteLine("PrivateProperty: >{0}<", accessor.PrivateProperty); 

Method Access

Based on this, it is simple to implement the access of non-public methods in the accessor base class.

// Implemented by PrivateAccessorBase
protected TReturnValue Invoke<TReturnValue>
  (
   params object[] parameter
  )
{
  return ((TReturnValue)PrivateObject.Invoke(
    new StackFrame(1, true).GetMethod().Name, parameter));
}

The accessor class uses this method like this:

// Usage by ClassToBeTestedAccessor
internal int PrivateMethod
  (
  string parameter
  )
{
  return (Invoke(parameter));
}

Using the PrivateAccessorBase together with a derived accessor class, the typo danger is eliminated. We got type safety, the accessor implementation does not contain PrivateObject usage, and there is a single place to be changed when some property or method names of the tested class will change.

Preconditions

There is only one precondition: The properties and methods names of the accessor class have to match 100 percent with the corresponding members of the tested class!

Avoid Inlining

One thing really important when using the StackFrame is to make sure the caller's name will not change. How might this happen? When the JIT compiler thinks it should optimize the code by inlining methods.

This would be fatal when using the call stack to get the name of the original caller. As soon as a method is inlined, the call stack changes.

Sample: Assume ClassToBeTestedAccessor.PrivateMethod will be optimized, because it only contains the call to PrivateAccessorBase.Invoke. In this case, the name of the caller in PrivateAccessorBase.Invoke won't be 'PrivateMethod' any more, but the name of the method that called ClassToBeTestedAccessor.PrivateMethod. Using this name, let's assume it is 'TestPrivateMethod', as the method name parameter of PrivateObject.Invoke, the test will fail with an exception, telling the method 'TestPrivateMethod' was not found.

Even if unit tests normally run in debug mode (the 'Optimize code' option is not set in the project's build configuration), one should be aware of this. To make sure the JIT compiler does not inline a method, set the [MethodImpl(MethodImplOptions.NoInlining)] attribute. The sample solution shows how and where.

Changes in .NET 4.5

In case you can use .NET 4.5 or above, you don't have to care about inline optimization 🙂

.NET 4.5 introduced the class CallerMemberNameAttribute. Using this class, there is no need to worry about these things. The attribute is processed by the C# compiler when it produces the IL code. Optimization is done by the JIT compiler later on (see forum post CallerMemberNameAttribute and Inlining).

For the .NET 4.5 implementation, the usage of MethodImpl and StackFrame is obsolete. The PrivateAccessorBase changes to this:

// Implemented by PrivateAccessorBase
protected TReturnValue GetPropertyValue<TReturnValue>
  (
  [CallerMemberName] string callerName = null
  )
{
  return ((TReturnValue)PrivateObject.GetProperty(callerName, null));
}

protected void SetPropertyValue
  (
  object value,
  [CallerMemberName] string callerName = null
  )
{
  PrivateObject.SetProperty(callerName, value, new object[] { });
}

protected TReturnValue Invoke<TReturnValue>
  (
  [CallerMemberName] string callerName = null,
  params object[] parameter
  )
{
  return ((TReturnValue)PrivateObject.Invoke(callerName, parameter));
}

Please notice that even the removal of the 'get_' / 'set_' prefix is not required any more.

The ClassToBeTestedAccessor has to name the parameter passed to PrivateAccessorBase.Invoke to make sure the first parameter is not interpreted as the caller method name.

// Implemented by ClassToBeTestedAccessor
internal string ProtectedMethod
  (
  string parameterValue
  )
{
  // Need to name the parameter, 
  // otherwise the first parameter will be 
  // interpreted as caller's name.
  return (Invoke(parameter: parameterValue));
}

Test Static Member

To access static class members, no class instance or PrivateObject is required. The PrivateAccessorBase collects all properties and methods the type defines, using the static constrcutor.

// Implemented by PrivateAccessorBase
private static IEnumerable DeclaredProperties { get; set; }

private static IEnumerable DeclaredMethods { get; set; }
…
static PrivateAccessorBase()
{
  TypeInfo typeInfo = typeof(T).GetTypeInfo();

  PrivateAccessorBase<T>.DeclaredProperties 
    = typeInfo.DeclaredProperties;

  PrivateAccessorBase<T>.DeclaredMethods 
    = typeInfo.DeclaredMethods;
}

One have to search for the property / method having the matching name, and invoke it.

// Implemented by PrivateAccessorBase
protected static TReturnValue GetStaticPropertyValue<TReturnValue>
  (
  [CallerMemberName] string callerName = null
  )
{
  return ((TReturnValue)PrivateAccessorBase<T>
    .DeclaredProperties
      .Single(info => info.Name.Equals(callerName))
        .GetValue(null));
}

protected static void SetStaticPropertyValue
  (
  object value,
  [CallerMemberName] string callerName = null
  )
{
  PrivateAccessorBase<T>.DeclaredProperties
    .Single(info => info.Name.Equals(callerName))
      .SetValue(null, value);
}

protected static void InvokeStatic
  (
  [CallerMemberName] string callerName = null,
  params object[] parameter
  )
{
  PrivateAccessorBase<T>.DeclaredMethods
    .Single(info => info.Name.Equals(callerName))
      .Invoke(null, parameter);
}

Please note that this is the .NET 4.5 implementation. For .NET version < 4.5, please refer to the sample solution.

Test Async Methods

Having the above in place, and putting it together with the description of the post Unit-Testing of Private Async Methods with Visual Studio, it is easy to extend the base class to be ready for calling async methods.

// Implemented by PrivateAccessorBase
protected async Task<TReturnValue> InvokeAsync<TReturnValue>
  (
  [CallerMemberName] string callerName = null,
  params object[] parameter
  )
{
  TReturnValue returnValue 
    = await (Task<TReturnValue>)PrivateObject
      .Invoke(callerName, parameter);

  return (returnValue);
}

The derived class uses it like this:

// Implemented by ClassToBeTestedAccessor
internal async Task<double> PrivateMethodWithReturnValueAsync
  (
  int millisecondsDelay,
  string outputText
  )
{
  double returnValue 
    = await InvokeAsync<double>
      (parameter: new object[] { millisecondsDelay, outputText });

  return (returnValue);
}

And the testing class uses the accessor this way:

// Implemented by ClassToBeTestedTest
[TestMethod]
public async Task TestPrivateMethodWithReturnValueAsync()
{
  int millisecondsDelay = 300;
  string testValue = "method unit test";

  ClassToBeTestedAccessor accessor 
    = new ClassToBeTestedAccessor();

  double result 
    = await accessor
      .PrivateMethodWithReturnValueAsync(millisecondsDelay, testValue);

  // Do validation stuff
}

Not Complete

The intention of this post and the sample solution is to give you an idea on how to create a home-made private accessor, and what to take care of when doing so.

The intention is not to offer a complete substitute of Visual Studio's Private Accessor Creation feature.

Accordingly, not all possible unit test scenarios are covered. Please feel free to extend the code for your needs and share your solutions and ideas with us by adding comments describing it.

Conclusion

Having this accessor base class, the creation of private accessors should be quite easy. Of course, not as easy as clicking a menu item, but better than fiddling around with PrivateObject.

The code snippets in this post might look a little bit complex and / or confusing. In this case, try to focus on the test class and accessor. Forget about the PrivateAccessorBase.

I hope you agree that both the creation of the accessor and the usage by the test class will be very comfortable and straightforward, having PrivateAccessorBase in place.

The Sample Solution

The sample solution contains four projects:

  • ConsoleApplication contains the class to be tested, based on .NET 4.0.
  • ConsoleApplication.4.5 contains the class to be tested, based on .NET 4.5.
  • ConsoleApplication.Test contains the PrivateAccessorBase, the accessor class, and the unit test class for ConsoleApplication, based on .NET 4.0.
  • ConsoleApplication.Test.4.5 contains the PrivateAccessorBase, the accessor class, and the unit test class for ConsoleApplication.4.5, based on .NET 4.5.

The class that is tested is ClassWithNonPublicMembers, located in the ConsoleApplication… projects.

You need Visual Studio 2012 or higher to build the solution.

Here you can download the code.

Test Explorer Output

Links

Upgrading Unit Tests from Visual Studio 2010

'Bring Back Private Accessor' suggestion on UserVoice

Eric Gunnerson's Compendium: Why doesn't C# have an 'inline' keyword?

CallerMemberNameAttribute

Forum question CallerMemberNameAttribute and Inlining

MSDN forum post How to create private accessors in VS 2012

Use Publicize.exe to Create Private Accessors for Visual Studio 2012+

Unit-Testing of Private Async Methods with Visual Studio

Description

Given there is the need to unit-test a private async method. The class to be tested might look like this:

public ClassWithPrivateAsyncMethod
{

// Some stuff

  private async Task PrivateMethodAsync
    (
    string input
    )
  {
    // Call some async framework method
    var result = await SomeFrameworkMethodAsync(input);
    // do something with the result
  }

// Some more stuff

}

In former – pre VS 2012 – times, one would have right-clicked inside this method, selected “Create Private Accessor…” and “Create Unit Tests…”, and implemented the test. Well, this was then, and this is now. Nowadays, Visual Studio does not have the ability to create private accessors and unit test bodies.

But still, you are able to create a unit test yourself. And instead of having a private accessor, we can use Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject, which is included in %Program Files (x86)%\Microsoft Visual Studio 11.0\Common7\IDE\ReferenceAssemblies\v4.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll (path might vary slightly with version changes, this is the path for Visual Studio 2012). To use this assembly, I had to set the Copy Local property of the reference to true.

Instead of wring much more prose, here is the implementation of the unit test method:

using Mut = Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestPlatform.UnitTestFramework;
// some other usings

[TestClass]
public ClassWithPrivateAsyncMethodTest
{
  [TestMethod]
  public async Task TestPrivateMethodAsync()
  {
    // Create an instance of the class to be tested.
    ClassWithPrivateAsyncMethod instance 
      = new ClassWithPrivateAsyncMethod();

    // Create a PrivateObject to access private methods of instance.
    Mut.PrivateObject privateObject 
      = new Mut.PrivateObject(instance);

    // Create parameter values
    object[] args = new object[] { "SomeValue" };

    // Call the method to be tested via reflection, 
    // pass the parameter, and await the return
    await (Task)privateObject.Invoke("PrivateMethodAsync", args);

    // Do some validation stuff
  }

// Some more stuff

}

Have a look at the checklist to be sure not to miss a detail.

Checklist

Check Combine async with return type Task in method declaration. Even if the method returns void, the declaration should be async Task. Otherwise, it cannot be awaited, what would lead to some trouble in testing the method.

Check Add reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll in your test project. You have to browse for it. The assembly can be found in %Program Files (x86)%\Microsoft Visual Studio 11.0\Common7\IDE\ReferenceAssemblies\v4.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll (path might vary slightly with version changes, this is the path for Visual Studio 2012).

Check Set Copy Local to true for the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll reference.

Check Declare an alias for the Microsoft.VisualStudio.TestTools.UnitTesting namespace if you also use Microsoft.VisualStudio.TestPlatform.UnitTestFramework. This helps you to avoid using classes of the wrong namespace. There are some overlappings.

Check Declare testing method async Task, not async void. Otherwise, it will not be recognized as a test method, even when the TestMethodAttribute is set.

Check Use PrivateObject to access private methods of instances. It is located in the namespace Microsoft.VisualStudio.TestTools.UnitTesting.

Check Cast PrivateObject.Invoke‘s return value to Task to make sure the call can be awaited.

Check Await PrivateObject.Invoke. Otherwise, the tests in the testing method might be performed before the tested method returns.

Links

Async Return Types (C# and Visual Basic)

Handling of Out-Parameters with .NET Reflection

Handling of Out-Parameters with .NET Reflection

Since Microsoft decided to remove the creation of private accessors for unit tests in Visual Studio 2012, one have to get familiar with the usage of Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject.

This class offers an easy way to call methods, independent from their visibility, via reflection. The method is PrivateObject.Invoke. This method saves you from getting the MethodInfo before being able to invoke an object’s ‘hidden’ method.

Sometimes methods do have out parameters. I was asking myself how to define these parameters when calling a method via reflection. When the method returns, I wanted to be able to read the value set by the method called.

I expected somthing tricky. But the solution is very simple: Just add an element to the array of parameters, and after the call access the appropriate element of the array.

The code goes like this:

ClassWithPrivateMethods instance = new ClassWithPrivateMethods();

PrivateObject privateObject = new PrivateObject(instance);

object[] args 
  = new object[] { "some value", null /* placeholder for out param */ };

privateObject.Invoke("PrivateMethodHavingOutParameter", args);

var outParameterValue = args[1];

Limitations of Private Accessors and Generic Methods (JIT Compiler Encountered an Internal Limitation)

Private accessors are really helpful for extensive unit testing. But they do have their limitations.

I wrote a generic protected method having a declaration like this:

protected ReturnType MyMethod<T>(OneClass, DateTime, DateTime, Func<OtherClass, T>, out List<T>);

Calling this method via an accessor in my unit test, I ran into an exception complaining “JIT Compiler encountered an internal limitation”.

First, I thought it was a LINQ issue, because I used LINQ inside to retrieve some data from a list, using the delegate passed. But I was wrong. Debugging into the test, the exception was thrown at the moment the method was called.

When I changed the declaration to

protected ReturnType MyMethod<T>(OneClass, DateTime, DateTime, Func<OtherClass, T>, out List<SomeType>);

the test finished successfully. But I had not implemented a generic method to be limited to the type of the resulting list.

Soon, the accessor got into suspicion. When I declared the generic version of the method as public, and used an instance of the implementing class, the test was successful too.

The solution in my case was to keep the method protected, derive a mock class from the implementing class in my test project, and use an instance of that derived class by the test.

Accessing Non-Public Member of Abstract Base Classes in Unit Tests

Given you have an abstract base class with non-public member, and a derived class with other non-public member too. Now you want to unit-test some of the non-public member (methods) of the derived class.

Prior the call of the method of the derived class, you need to set some non-public properties declared in the base class.

The problem I ran into was, that, using the derived class’ accessor, I was not able to access the properties of the base class. But without setting them, I can’t test the method.

The solution is somewhat uncommon, but it works. You need two private accessors, ‘pointing’ to the same object. Use the one to manipulate the base class’ member, and the other to access the derived class’ member. Since both accessors point to the same object, you do access that single object. See the code below:

DerivedClass instance = new DerivedClass();

BaseClass_Accessor baseAccessor 
  = new BaseClass_Accessor(new PrivateObject(instance, 
      new PrivateType(typeof(DerivedClass))));

baseAccessor.ProtectedProperty = someValue;

DerivedClass_Accessor accessor 
  = new DerivedClass_Accessor(new PrivateObject(instance));

accessor.CallMethodToTest();