You’ve probably seen all the various announcements from Microsoft today, with the most notable being the release of Visual Studio 2015 Preview and the jaw dropping move to open source the .NET Core Framework. Fantastic stuff! Though I won’t go into it in detail here.

What I do want to cover are the “Smart Unit Tests” released with the VS2015 Preview, based on the Microsoft Pex research project. The messaging around it has created more than a little confusion. In fact, here’s what one of my colleagues on Twitter sent my way:

During the MVP Summit I spent some time with the people who built this feature to better understand what the intent behind these so called “smart” unit tests. Is it simply so we can tell our managers that we can hit that magic 100% unit test coverage mark now, meet our KPI’s, claim our annual bonus for hitting an arbitrary metric, and still be able to produce rubbish quality applications or is there some other value to it?

It turns out that the purpose of the Smart Unit Test feature is to help people in their refactoring efforts. It’s good practice before you go and refactor code to ensure you have a healthy level of test coverage in place so that you can be confident that any changes you make to code don’t break the behaviour of the application. On existing, legacy code without tests, this is often a very expensive and difficult process, and as a result many refactoring efforts occur either without any test coverage at all or simply never happen because they’re too scary.

This is where “Smart Unit Tests” come into play. They help you do the “smart” thing and create unit tests that help you pin down the current behaviour of the code, before you do any refactoring.  These type of tests are known, unsurprisingly, as pinning tests.

Here’s a good description of a pinning test (source), emphasis added:

A “pinning test” is not a good test. It doesn’t try to be. It’s just the simplest, fastest-running test you can write that will allow you to refactor your code. It’s often an end-to-end test, but it could also look at your log files, monkey-patch a core library function, or do something similarly ridiculous.

The key here is that the pinning test lets you do your dozens-of-tiny-refactorings loop really quickly. As the code improves, you add high-quality unit tests. Once the tests are good enough, you get rid of the pinning test. Lather, rinse, repeat.

Hopefully that helps clear up some confusion. Oh, as a final note, Brian Harry mentioned that the Smart Unit Tests name is likely to change. Let’s hope so! :-)