.NET TDD Resources

I was doing a little browsing and ran across several items of interest.

First, let me join the voice of many who love Lutz Roeder's .NET Reflector. This tool absolutely rocks. I wish it were a visual studio add-in replacement for the "Go To Definition" and "Go To Reference" options, because it is sooo much nicer.

There is an add-in (yes, Reflector has an add-in api!) by Jonathan de Halleux called Reflector.Graph. You can see some snapshots of what it can do on his blog. His blog is excellent reading material. Apparently, Microsoft took notice, because they recently hired Jonathan.

Advanced Unit Testing is a collection of tools, practices, and patterns for unit testing, especially focused on .NET. Core to AUT is the MBUnit testing framework by (again) Jonathan de Halleux. Jonathan also has a production grammar framework, some graphing libraries (implemented on top of AT&T Research's GraphViz), unit test generation tools, and more. Very, very good stuff.

Marc Clifton created AUT, and he has a number of articles on Unit Testing over at Code Project. Good stuff as well.

Finally, Roy Osherove has an interesting article that extends some ideas ideas presented in James Newkirk, et al.'s Testing in Microsoft.NET to leverage Enterprise Services in database testing to rollback any changes that are the result of the test.

In my experience, even in organizations that are aware or actively trying to adopt test-driven development or *at* *least* implement decent regression test suites for their applications, there is a constant struggle to develop the tests. In my experience, the amount of test code necessary to test a component well is 2-3 times the amount of code necessary to implement the functionality. it is good to see so much activity in this area in terms of helping people understand best practices and providing tools to automate some of the more redundant bits can help narrow the gap. Of course, tools alone won't necessarily make the job easier. You must properly apply them. But all of the infrastructure certainly lowers the barrier to entry to increasing the quality of code.

I was talking to a one-time cohort about TDD a while back, and he influenced how I think about it. He basically said (paraphrased) that TDD is not so much a testing method or a coding method as it is a *design* method.

I hope you had a nice weekend.

Comments

[One-Time Cohort]

for me, TDD is about specifying executable requirements of various components of the system. e.g. i have a requirement that the system calculate present-value-of-money on an equipment lease contract. ok, great. who'll do it? ah, maybe there are Contract objects, with data required to perform PV-of-money calculations. great, i imagine a method computePresentValue() on it. what does it answer? ok, a Money value object...let's write a simple test... now, you say that you use different terms for the PV-of-money calc for a contract based on certain properties of the contract -- lessor code, business segment...write specifications of those scenarios as executable tests too...