This post is just a quick note to point folks to two things that I have found make me much more productive building .Net apps. There are lots of things that could be named in this camp including ReSharper and PowerShell and what have you. (Scott Hanselman, by the way, maintains a whole monster list.) There are two, though, that have had a surprisingly profound impact on me and my team.
If you are serious about building unit tests for your code (whether you religiously write them test-first or not), a phenomena which you will encounter pretty quickly on any decent sized project is that you have a LOT of tests which you want to run regularly.
In addition, I often find that I have a mix of true unit tests and others which are really integration tests. The biggest difference between these two from a practical standpoint of interacting with them is that my unit tests are very safe (no side effects) and automatic (no pre-run setup needed) while my integration tests often need me to fire up multiple programs and do a little setup before running them.
Both kinds of tests are super useful, and when I’m working in a particular area it’s usually no big deal to run relevant tests. ReSharper makes that easy—just click on the icon in the left margin of the test code. Running tests in other parts of the code base, however, takes more effort mostly because it takes more time. You have to build everything, then you either have to think carefully about what tests need run or run everything and then wait for all the tests to complete, etc. The result of this extra friction is that it often doesn’t get done. Of course my CI build (which I’ll talk more about below) will catch errors after I check in, but every moment bugs live in my code increases the cost/pain associated with fixing them. Not only does the cost go up if I check in and then have to come back to the bug later (after someone else may have had to deal with it as well), but it also goes up even when I just context switch away from the code I just wrote which caused the bug. Ideally I would see test failures caused by code changes immediately upon making those changes.
That’s what NCrunch does. It’s amazing. Basically it constantly monitors changes you make in visual studio and intelligently builds and runs tests as needed based on the code you change—even before you save. It then quietly in the background updates an icon in the lower right of the screen indicating if there are problems and maintains a window with a list of projects that don’t build or tests that aren’t passing. It also shows in the left margin of each line a little dot that indicates if the line is covered by unit tests or not and if so whether or not those tests are passing. So you immediately get feedback which helps you see and right away fix any tests that are failing. Awesome!
Visual Studio Team Service
The other tool which has had a major impact on my team lately is TFS in the cloud. Especially for small teams like mine where the service is free, this service has been huge. With a few clicks I had setup a source control server which is accessible from anywhere on the internet, includes support for bugs/tasks/planning integrated into VS2012, automatically sends email notifications to team members on checkins and bug changes, and even does continuous integration builds and runs tests whenever a checkin is made.
In addition the new support for code reviews in VS2012 works beautifully with this system. My team spent nearly a year using mercurial with bitbucket which wasn’t bad, but the switch to TFS in the cloud was transformative. Before that switch code reviews had so much friction that they just didn’t get done regularly, and now every checkin gets reviewed. Previously we had unit tests but no CI server configured to guarantee they were run on each checkin. In addition we just hadn’t been able to find a task/bug tracking system that worked for us, and now we have a first class system integrated with VS, and we’re using it.
Both of these tools are awesome. I suggest you go give them a try right now.