Visual Studio 2013 has an awesome feature for those who like debugging. One limitation before Visual Studio 2013 was that we couldn’t see the return value of a method, neither the return value of the method that call other method. Now, with Visual Studio 2013, it’s possible to see the return value with the Debugging windows “Auto”. It’s also possible to see returning value by using the $ReturnValue keyword in the immediate windows.

Here is an example.

class Program
{
	static void Main(string[] args)
	{
		var x = Method1();
		Console.WriteLine(x);
		Console.ReadLine();
	}


	private static string Method1()
	{
		return "Method1 call " + Method2();
	}

	private static string Method2()
	{
		return "From Method2" + Method3();
	}

	private static string Method3()
	{
		return "From Method3";
	}
}

If we set a breakpoint to the Method1 and we hit next, we will be at the ending curly bracket. Normally, we won’t see the value of “Method1 call ” + Method2();

Now, we can see it.

As you can see in the image above, we see in the corner left bottom the Auto Windows Panel. The first line is the value inside Method2() and the second line is the return value of Method1().

Visual Studio 2013 let you have two type of scroll bar. The first one is the same at in Visual Studio 2012 which contain additional information like where errors are located with a red rectangle and allow you to mark every keyword searched with a yellow mark. It also contain a dark brown color for break point and a blue line for the current line. The last thing it can display is what has changed.

Now, you can switch to have a visual representation of the code. This new scroll bar visualization is called the map mode.

To activate the map mode, right click on any scroll bar and select the options entry in the context menu.

This will bring the options menu for the scroll bar. At the right of the dialog window, a behavior frame contains the two available options.

Not only you can see the code but you can also if you put you mouse over the scroll bar see what the code is.

The main goal of this new feature is to allow you to move less when developing. It allows developer to not move back and forth inside a page. With the combination of the peak definition feature, the focus remains more and more into the task and not to move around files and lines.

Visual Studio 2013 brings many new improvements and one of this one is the peak definition feature. This feature is available by the default shortcut alt+F12 when the caret of your mouse is on a method.

The goal of the peak definition is to display the content of the method inside the file, where the method is called. A picture worth a thousand words, so here is an example. I have clicked the AddValidationErrors and I have pressed alt+F12. What happen, is that a block with the title “controllersextension.cs” appears. It displays the code that would been called. You can close this window any time by clicking the “X” or by pressing escape.

The goal of this feature is to limit the number of file open for just watching what’s happening. It’s very fast, and allow to have a peak of what’s happening. The only limit this new tool has is that it doesn’t work well when the method is from an interface. In that case, you see the interface definition.

Microsoft has the ability to fake method but as the disadvantage that it requires to be from an interface or to be virtual. This is the case of most testing framework. Nevertheless, Microsoft has the principle of Shim which allow to replace the method behavior by yours for the time of a test. You can get additional information on MSDN. This blog article explains briefly how to use shim.

For the purpose of this article, let say that we have a library with a single class which contain a single method :

namespace ShimpProjectClassesToShim
{
    public class MyClass
    {
        public string MyMethod(string variable)
        {
            return "From MyClass = " + variable;
        }
    }
    public class MyClass2
    {
        public string ToTest()
        {
            var m = new MyClass();
            return m.MyMethod("InsideMyClass2");
        }
    }
}

This method is not virtual, but could have been because shim can be bound to static method. As you can see, the purpose of the test would be to change the inside of the method for the time of a test method.

To continue with our example, we need a second project, the one of the test. This one will have a reference to the library previously created. Once done, right click the reference and click “Add Fake Assembly“.

Do no worry, you have already added the reference from the unit project to the library project. Maybe a better naming of the action should have been “Transform to Fake Assembly. When done, you will see a Fakes folder created with the fake reference.

If you are curious about what contain this file, here is the one of the example :

<Fakes xmlns="http://schemas.microsoft.com/fakes/2011/">
  <Assembly Name="ShimpProjectClassesToShim"/>
</Fakes>

So the test will consist of shimming MyClass that is used by MyClass2. This is a common scenario that you want to test a method that use an other class that you do not want to test. In our case, we want to test MyClass2 and not MyClass, we shim MyClass to have a known return value.

The test my be inside the scope of a ShimContext to be able to set the shim inside the test.

[TestClass]
public class UnitTest1
{
	[TestMethod]
	public void TestMethod1()
	{
		//Shim
		using (ShimsContext.Create())
		{
			//Arrange
			ShimMyClass.AllInstances.MyMethodString = (theClass, s) => "FAKE " + s;
			var classToUnitTest = new MyClass2();

			//Act
			string result = classToUnitTest.ToTest();

			//Assert
			Assert.AreEqual("FAKE InsideMyClass2", result);
		}
	}
}

The arrange section set for all instances of the method the desired return value. As you can see we use “ShimMyClass” class to set all instances. In your case, if you class is called “XYZ”, you will have to use “ShimXYZ”. This is by design that a class has been created for you with the prefix Shim. From there, you will be able to set return value for all methods. The rest of the unit test is as usual.