Visual Studio TDD setup

I'm a C# developer new to TDD willing to experimen开发者_Go百科t 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?

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.

You might want to use some code snippets for testing.

http://www.codeproject.com/KB/dotnet/UnitTestCodeSnips.aspx

There might be some conflicts with R#.

I find the trick of setting up NUnit to auto-run tests on reload very nifty.

Tools > Settings > Test Loader (tree) > Assembly Reload > Re-run last tests run

This compresses build-and-run-tests into a single step.

Tools will only make you faster to a point... beyond that the real boost comes up from reflecting on your TDD method. Read, Practice, Reflect and Adapt.

My personal additions

• track TDD rhythm (Red-Green-Refactor)
• track time spent in broken builds state (compile/test errors)
• run tests on build and view result in IDE
• get failure traces in IDE

Got the first three done as part of a VS Extension... WIP.

Update: This was unstated but... streamline all routine stuff. e.g. use tools to refactor, use code-templates/snippets for freq used code patterns, become one with your IDE (master keyboard shortcuts to all freq-used actions, bind keystrokes to ones that don't have one)

Keeping the build time low. You will need to frequently run the tests. Here are a few things I do.

1. Watch out for pre-build events that slow things down
2. Make sure you only build projects as needed. In visual studio 2010, check Tools - Options - Projects and Solutions - Build and Run - Only build startup projects and dependencies on run
3. Make sure to keep your tests running fast. The unit tests shouldn't have much being done. It should be possible to run dozens to hundreds per second on a current machine.
4. Split unit tests and integration tests. Run unit tests more frequently. Of course, run all tests before you commit to the shared version control system.