I don’t like development friction. I especially don’t like testing friction. Over the last several years, my approach to test-driven development and the style of test cases I create has changed drastically in an effort to eliminate testing frication. To illustrate, I’ve created my first ever screencasts. In these screencasts, I use TDD to implement a class in RageFeed. Starting with very coarse, high-friction unit tests, I’ll show you how you can gradually reduce the friction by creating better tests. Finally, I’ll show you how easy it is to create clean, readable, specification-style tests in RageFeed today.
Note: I apologize for the limitations of ScreenToaster’s player. I’m in the process of mirroring the videos elsewhere, and I’ll update the post with links as soon as I get around to doing that.
In these screencasts, you’ll see me use a variety of tools. They are:
Test-Driven Development - Part 1 (View)
In part 1, I introduce the class I’m going to be implementing, and I use TDD to flesh out the class. I intentionally create my tests as I would have several years ago (meaning they suck). From there, I gradually evolve them into a better suite of tests, but there’s still room for improvement.
Test-Drivent Development - Part 2 (View)
In part 2, I leverage some ReSharper templates and some base classes I’ve created in RageFeed to create replace my tests with behavior-driven development style specifications. The result is (near) zero friction testing.
I’ve packaged up the base SpecsFor<T> class as well as my ReSharper templates. Feel free to use them for whatever you like!
Download SpecsFor and ReSharper Templates: download
I’m certainly not claiming that what we have in RageFeed is The One Way to do testing in .NET. It works well for me, but I’d love to hear what others think. Also, this is my first ever screencast, so please drop me a line and let me know what you liked, what you didn’t like, and what you’d like to see in future screencasts (assuming I actually do more).