Recently I’ve been playing around a lot with JavaScript modules. The particular use case I’ve been thinking about is the creation of a large complex JavaScript library in a modular and sensible way. JavaScript doesn’t really do this very well. It does it so poorly, in fact, that a sizeable number of projects are all done in a single file. I did fine a number that used file concatenation to assemble the output scrpit, but this seems like a stone-age technique to me.

This led me to look at the two competing JavaScript module techniques: Asynchronous Module Definition (AMD) and CommonJS (CJS). AMD is the technique used in RequireJS) and CommonJS is the technique used by nodejs.

Last month I wrote an article for Visual Studio Magazine called, “What Really Matters in Developer Testing” that I wanted to share with my readers here.

Note: They changed the title and made a few other tweaks here and there, so this is my original manuscript as opposed to the edited and published version. Enjoy!

If you’d prefer, you can read the published article here:
http://visualstudiomagazine.com/articles/2013/08/01/what-really-matters-in-developer-testing.aspx?m=1

For a couple of weeks I’ve been playing around with some of the updated tools I use to make this blog. Back in April 2012, I pulled all of my content out of a server-side ASP.NET blog engine and moved to Jekyll and Octopress. Honestly, I can’t see myself going back.

But it has been more than a year since I created the current skin, and it was time for change. Also, Jekyll has matured a lot and many of the things that Octopress brought to the table are no longer needed. So I decided to kill two birds with one stone and update the whole thing… generator and skin.

Of course I want a responsive layout, and for a long time my go-to framework has been Twitter Bootstrap. But TWBS has a few issues that have started to bug me, most notably the way it handles font-sizes. So I decided to begin an investigation of available frameworks and toolsets.

Update 2013-08-29: We got mentioned in This Week on Channel 9 today. Woot!

This morning I did an interview on Radio TFS, hosted by Martin Woodward and Greg Duncan. The topic was “What have you been working on since Visual Studio 2012”, and we had a great time talking about all the cool stuff we’ve done in the VS2012 updates and what we’re targeting for Visual Studio 2013.

You can download & listen to the interview here:
Episode 64: Peter Provost on Visual Studio 2013 Ultimate

Many thanks to Martin and Greg for having me. It was fun and I’m looking forward to doing it again so we can talk more about developer testing.

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.