With test driven, I take the "standard" TDD approach (something like):

• write test (based on a use case etc)
• build the app (will fail because code is not there etc)
• implement code the code required to get the build compiling
• run test (test will fail becasue the code stub does nothing useful)
• implement code - run test and repeat until passed
• refactor as required - run tests

Then apply then to Visual Studio 2005... The results of following this procedure need to be experienced to really understand the benefits if you are not farmiliar with TDD etc.

I also make use to a couple of manually created keyboard shortcuts, Ctl+ALT+T and Ctl+ALT+R which
execute TestDriven.NET's "Run Test(s)" and "Repeat Test Runs" context menu options respectively.

Here is my TDD with TestDriven.NET and VS.Net 2005's handy smart menus and refactoring capabilities:

• Create the class stub if its the first test for the class
  (I find the compiler telling me that I am missing a class kind of superfluous, I still follow this process sometimes about 50-50)
• Write test (based on a use case etc)
• Before I build the application, I normally know which methods are missing so instead of performing failing build I use the smart menu to generate the stub for me (use the shortcut keys Shift+ALT+F10, then enter)
• Run the test with Ctl+ALT+T (TestDriven.NET will perform a build as required, the test will - or should - fail because the code stub does nothing useful)
  Use the "Escape" key to get out of the "Output" window after a test run.
• Implement enough code to pass the test - run test and repeat until passed using Ctl+ALT+R to execute the "Repeat Test Runs" option.
  Again, use the "Escape" key to get out of the "Output" window after a test run.
• Refactor as required - run tests (Ctl+ALT+R)

Following this procedure helps me keep the focus on the requirements in a very efficient manner with minimal flicking between windows, initiating builds etc.

Using the InternalsVisibleTo attribute to get access to another classes internal methods for testing.

Jamie has put together a nice screencast of some of TestDriven.NET's new features, check it out:

http://weblogs.asp.net/nunitaddin/archive/2006/11/11/Testing-With-NCover_2F00_NCoverExplorer.aspx

This is an article on extending the excellent ICShardCode TextEditor to support addition syntax highlighting styles. Its quite straight forward.

Extending ICSharpCode.TextEditor to support additional Syntax Highlighting

 

On my site I have an area for articles: http://www.pksoftware.net/Articles.aspx.

Blogs are good for getting information out there but I find they get messy quickly and finding stuff becomes a pain.

When I first started trying out TDD and (more so when I started using the TestDriven.Net), I still spend a good chunk of my test development time stepping through the code line by line, checking the state of variable etc. It took me a while to kick the habit, but when you get stuck into TDD you won't be spending anywhere near as much time stepping through your code trying to work out what’s going wrong as you probably used to.
Why? Because the unit tests you write in an incremental fashion, build slowly on the last and in turn your confidence in the code is greater – you no longer feel the need to step through the code. When I run a test that fails now I can usually spot the issue relatively quickly without having to "step in". Those small TDD steps really pay off.
Don't get me wrong, I still step into my code when I get a curly one, but it's more the odd occasion now than the natural response.
Stay out of that debugger - it will save you a lot of time :-)

Why would anyone have a problem paying a (small amount) for a great piece of productivity software? Jamie Cansdale has been copping flack about making TestDriven.Net a commercial product...

NCover Explorer is one of my "Must Have Apps"...