Review: Visual Studio 2013 reaches beyond the IDE
Microsoft delivers editing, debugging, deployment, project architecture, and ALM improvements stretching from Windows to Web development, from mobile devices to clouds
Energy consumption is a new consideration for desktop and server application developers, although it has been a driving concern for mobile application developers for years. If just one desktop developer learns to replace his busy-wait loops with async code while profiling Windows Store apps, the world will be a better place.
The improvements I discuss in this section were actually introduced in Visual Studio 2012 Ultimate, but I think they are important enough to include here.
Test-driven development (TDD) is near and dear to my heart, but I didn't used to be able to practice it on Microsoft code the way I could on Ruby code, though I was an early adopter of NUnit. What made TDD untenable for me was that IntelliSense would blindly autocomplete the names of stubs I hadn't yet written to some random but similar label.
Improvements to IntelliSense over the years alleviated this problem somewhat, and Visual Studio 2010 brought unit testing into the tent in a way that was only moderately incompatible with NUnit. The Test Explorer in Visual Studio 2012 unified NUnit and MSTest, as well as unified .Net and unmanaged C++ unit testing. Another set of essential features for TDD was introduced at that time: Microsoft Fakes.
The Fakes framework generates mocks for classes and APIs that you want to exclude from a unit test. For example, you don't want to unit test from live data; it changes from run to run, and the test will fail even though it's working correctly. Instead, you want to unit test from fixed data and with APIs that always return the same results. Indeed, for a unit test, you want to use a stopped clock, not
There are two categories of Fakes: stubs and shims. Stubs are mocked classes generated by the Fakes framework. You use them to isolate the classes under test from other classes in your application that return variable results. Shims are runtime modifications of your calls to external applications, services, and system APIs. Ideally, you would always use stubs when they were applicable, and you would only use shims when forced. On the other hand, if you're lazy, shims will always work, albeit slowly.
If you've installed the current Windows Azure SDK, you can create Azure sites and databases directly from Visual Studio 2013.