Visual Studio TDD setup

Question

I'm a C# developer new to TDD willing to experiment with this development methodology.

My current setup is Visual Studio 2010 + Resharper (very convenient for running Unit Tests - set up a Unit Test Session and there are the Run and Debug Tests buttons).

Still, I feel like there may be ways to accelerate TDD even more (e.g.: when saving a tests file automatically run the tests in it).

So, TDD experts using Visual Studio - can you share any tips about how to make the TDD process more productive?

Answer 1

Tools

I typically bind a keyboard shortcut to the Context Run. You can do this in Visual Studio's options by hitting "Tools", "Options", and under "Environment -> Keyboard" you can find "ReSharper.ReSharper_ReSharper_UnitTest_RunContext". I believe Resharper 6 will assign a keyboard shortcut to it, Ctrl+T, R. I've typically always assigned it Alt+;.

This will run the unit tests in context. So if your cursor is inside of the test you just finished writing; that test gets run. If the cursor is inside of the Test Class / Test Fixture; that gets run.

You can also make some R# templates. I typically make a template called Test that looks like this:

[Test] //NUnit Change attribute to [TestMethod] if MSTest.
public void $NAME$()
{
    $END$
}

I prefer R# templates over Visual Studio code snippets because you can make "Solution" level templates that gets stored in an XML file along side the solution file. So when you check it in; all of your colleagues have access to the templates as well; or even you from another workstation.

This way you can keep adding tests without all of the boilerplate stuff. You can even make file templates for whole fixtures.

The real trick to getting it going fluidly is learning all of the keyboard shortcuts. Once you know them and master them; your hands start doing it without even thinking. Add / Modify a test and you'll start to automatically press the context run command (whatever one you might use) without even thinking.

Continuous Integration

Another unrelated tool; but very powerful every TDDer should become familiar with is a Continuous Integration (CI) server. This will allow you to run tests whenever you checkin to source control. Eventually projects big enough will get suites of 1000's of tests. Running them all of the time yourself becomes unpractical. A CI server, like TeamCity, will run your tests on a server when you check in. Then it will report everything that is broken when it is done; so you can keep working while it runs other tests. Ones you might not have thought you broke but did. There are some other good free ones available; like Hudson. EDIT: As Peter pointed out in the comments; CruiseControl.NET is an open source CI server that's been around for a while; definitely worth checking out.

My typical guideline is run the tests that I think are relavant. I use NUnit which has a [Category] Attribute. I run all categories that I think are affected; and let the CI server take care of the rest.

Coding Discipline

Tests are code too. They need to be refactored; and maintained. I've seen so many people give up on testing because they ended up with spaghetti tests. Keep your unit tests focused on a small, single unit. It starts to slow down you and your team when tests are brittle. Generally, without going into too much detail; following the SOLID principles helps with testing.