This year at both TechEd North America and TechEd Europe I gave a presentation called “Testing Untestable Code with Visual Studio Fakes”. So far VS Fakes has been very well received by customers, and most people seemed to understand my feelings about when (and when not) to use Shims (see Part 2 for more on this). But one thing that has consistently come up has been questions about Behavioral Verification.

I talked about this briefly in Part 1 of this series, but let me rehash a few of the important points:

• Stubs are dummy implementations of interfaces or abstract classes that you use while unit testing to provide concrete, predictable instances to fulfill the dependencies of your system under test.
• Mocks are Stubs that provide the ability to verify calls on the Stub, typically including things like the number of calls made, the arguments passed in, etc.

With Visual Studio Fakes, introduced in Visual Studio 2012 Ultimate, we are providing the ability to generate fast running, easy to use Stubs, but they are not Mocks. They do not come with any kind of behavioral verification built in. But as I showed at TechEd Europe, there are hooks available in the framework that allow one to perform this kind of verification. This post will show you how they work and how to use them to create your own Mocks.

I know this post is probably going to make a lot of people say, “Holy crap, man. If you need that much of a system, you get too much email.” All I can say is “Guilty as charged, but I know I’m not the only one with this problem.” So if you find this useful, great. If not, move on.

I’ve long been a fan of the whole Inbox Zero idea. While the concept of using other kinds of task lists (e.g. Outlook Tasks, Trello or Personal Kanban) is nice, in my experience the Inbox is a much more natural place to keep track of the things I need to do. Like it or not, a large number of us in the tech sector use email as our primary personal project management system. I don’t think this is just a “Microsoft PM” thing, but certainly the amount of email that happens here, in this role, makes it more the case.

Near the end of the development cycle for Visual Studio 2012, a group of folks in the VSALM team (led by my very creative manager Tracey Trewin) came up with this cool animated video introducing some of the great new features in Visual Studio 2012 Ultimate. I think it is pretty cool, and even pretty funny, so I wanted to share it with you all.

What do you think?

In my last post I focused on how to unit test a new Visual Studio 2012 RC ASP.NET Web API project. In general, it was pretty straightforward, but when I had Web API methods that needed to return an HttpResponseMessage, it got a little harder.

If you recall, I decided to start with the Creating a Web API that Supports CRUD Operations tutorial and the provided solution that came with it. That project did not use any form of dependency inversion to resolve the controller’s need for a ProductRepository. My solution in that post was to use manual dependency injection and a default value. But in the real world I would probably reach for a dependency injection framework to avoid having to do all the resolution wiring throughout my code.

In this post I am going to convert the manual injection I used in the last post to one that uses the Ninject framework. Of course you can use any other framework you wanted like Unity, Castle Windsor, StructureMap, etc. but the code that adapts between it and ASP.NET Web API will probably have to be different.

A couple of days ago a colleague pinged me wanting to talk about unit testing an ASP.NET Web API project. In particular he was having a hard time testing the POST controller, but it got me thinking I needed to explore unit testing the new Web API stuff.

Since it is always fun to add unit tests to someone else’s codebase, I decided to start by using the tutorial called Creating a Web API that Supports CRUD Operations and the provided solution available on www.asp.net.

I’ve been working on a series of posts about authoring a new unit test plugin for Visual Studio 2012, but today my friend Matthew Manela, author of the Chutzpah test plugin, sent me a post he did a few days ago that discusses the main interfaces he had to use to make his plugin.

The Chutzpah plugin runs JavaScript unit tests that are written in either the QUnit or Jasmine test frameworks. Since JavaScript files don’t get compiled into a DLL or EXE, he had to create custom implementations of what we call a test container.

I’m getting ready for TechEd 2012 this month and realized I wanted to have a nice desktop wallpaper for my laptop. Well, I’d not seen any popping up on twitter or blogs yet, so I grabbed my trusty GIMP image editor and some base images of the new VS 2012 logo and got to work.

Here are a few of my favorites, but I’ve not decided which I will use on my laptop.

I tweeted a bit about the craziness coming up for me in June, but I realized today that I’ve not posted the whole schedule. So if you’re interested and wondering what I’ll be talking about, here’s the complete list (in chonological order).

The first two are now behind me, but the twin TechEds are coming up fast. Also, I’ve got a couple that are currently “maybes” so once they are confirmed I’ll update this post. If you want to contact me about speaking at an event, please use my about.me contact page.

The simple answer: Just Say No™

Every now and then I get an email, see a forum post, or get a query at a conference about this topic. It typically goes like this:

“When you’re doing TDD, how do you test your private methods?”

The answer of course, is simple: You don’t. And you shouldn’t.

This has been written up in numerous places, by many people smarter than I, but apparently there are still people who don’t understand our point.

Good news!! Last night I got an email from Charlie Poole, the maintainer of NUnit pointing me to a blog post he’d just made:

Today, I’m releasing version 0.92 of the NUnit Adapter for Visual Studio and
creating a new project under the NUnit umbrella to hold it’s source code, track
bugs, etc.

In case you didn’t know, Visual Studio 11 has a unit test window, which
supports running tests using any test framework for which an adapter has been
installed. The NUnit adapter has been available on Code Gallery since the
initial VS Developer preview. This release fixes some problems with running
tests that target .NET 2.0/3.5 and with debugging through tests in the unit
test window.