28. November 2006 02:45
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
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
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.