February | 2015 | // ThomasWeller

TDD is not about testing, it’s about how we develop software

I am practicing Test Driven Development (TDD) now for some two years or so, and soon this technique of writing software felt so natural, that I hardly could imagine doing it another way or even imagine a reason why I should do so. But on the other hand, I know that not questioning something anymore and not being self-critical from time to time is a certain recipe for running into a disaster sooner or later. So I asked myself: What makes TDD such a natural way of writing software? and What are your main conceptions about TDD? This post is the result of my reflections.

Unit testing StyleCop rules

15/02/2015 / thomas-weller / No Comments

Note
I originally wrote this post back in November 2009 over at my old blog at geekswithblogs.net. Because it still receives some hits, I decided to take it with me and copied it to my new blog. With the exception of some necessary HTML polishing, this article is unchanged compared to its previous version.
The Gallio testing framework (which essentially is MbUnit) that I was using at this time, is no longer available. But it’s very similar to NUnit and you can easily read the code samples if you’re familiar with NUnit. I updated the accompanying sample solution to use NUnit (but not the code excerpts in this post). Also, I updated it to VS 2013 and NuGet and gave it a new home on Github.)

One of the single most influential cost factors for software projects is code readability and understandability – and the most important factor for readability in turn lies in the adherence to Coding Style Guidelines. To enforce such guidelines, Microsoft has provided a free tool which checks a given set of source code files against a given set of style and consistency rules: MS StyleCop. The tool comes with quite a lot of predefined rules – however, they mirror the coding practice at MS and not all of them may be appropriate or sufficient for others. Therefore, StyleCop allows for authoring custom rules to extend or modify the original set of rules. How this can be done, is well covered elsewhere on the web (e.g. here, here, or here).

But in contrary to the rules authoring issue, very little – almost nothing – can be found that deals with testing issues. All I found was this post, which gave me a first insight into the issue and inspired me to write a custom Gallio/MbUnit test fixture that lets you write tests against StyleCop rules as simple as this: