TDD tools for .net developers

09Jul11

In the last few years the tooling available to .net developers for unit testing in general has matured, these are some of the tools  that I either used or heard of :

Continuous Integration:

  • Team City: I use it and really like it, simple to set up and use, if you want to try it they have a free professional edition .
  • Cruise Control.net: Open source, used it but didnt find it too friendly, I m aware a lot of people use it
  • Hudson. Originally a Java only project but there are some success stories on the .net fence, has some features unavailable in the other two mentioned above.
  • there must be something else. ?
BDD Frameworks
  • StoryQ:  This is what I use. Like it because you write C# code with some constraints and it generates reports on the behaviour. Samples: code report
  • Cukes/Cucumber: I remember the first time I saw cucumber in action I was really impressed, however it’s hard to get buy in for a tool that requires another language installed, probably fine for some projects, it depends a lot on the project, the company and the culture.
  • SpecFlow:  you write features in Gherkin(the cucumber spec language) that are then compiled into c# code. Nice reports, but I find the generated code hard to read… ie a bit too verbose (example feature example generated code) however I wouldnt discard it totally.
  • NSpec:  You write c# code (very lambda-y)  and it generates reports.. like it even less for reasons similar to the above,  have a look at it yourself here
  • Fit/fitnesse:  I haven’t tried it, it supposed to be very good, I ll leave that one to you (would love some feedback on this if anyone reading did try it)
Unit Testing Frameworks.
  • xUnit: a nice, compact unit test framework, I like it because it has less noise,  no setup method (ie it uses the ctor for
  • nUnit:  The most popular one.
  • mbUnit: good support for RowTests.
  • _
  • msTests: the option by Microsoft. I tried this framework when it came out, so perhaps not valid anymore. My experience with it was that the same set of test ran 20% slower. Also it had poor support for theory tests. Maybe this all changed. I will guess that anyone using this framework does it because they can’t use anything else
Builds
  • Psake:  powershel based DSL for building
  • Rake:  Ruby based Dsl for builds, nice to use ruby, but sometimes needing the ruby dependency is a deal breaker
  • Nant: not something I would choose, but hey if you like xml this is the way to go (if you like Xml you might want to talk to your doctor too 😉 )
  • MSBuild:  I find it non intuitive, I thought I was being unfair so I asked in twitter what ppl thought of it. One supporter and 4 not really happy with it (see below)
  • Final Builder : a commercial option, and not a bad one to be honest. Very easy to use (drag drop style) tho not as flexible as we needed.
Code Coverage
  •  NCover: does the job but I think the generated graph could be better. Running the tool was cumbersome too as far as I remember
  •  dotCover : really nice and integrated with resharper, it a bit rough around the edges with lambdas and other minor things, but a tool I use day to day
Feedback and anything that wasn’t mentioned yet , please feel free to comment
Cheers
Advertisements


7 Responses to “TDD tools for .net developers”

  1. 1 kenegozi

    As for build scripts – a great tool for .NET-ers is phantom, a boo-based dsl

    Why I like it?

    1. Very low noise. Comparable to rake
    2. No real dependency. Rake needs a whole Ruby, psake require PS (which is not always there, especially if you wan Mono builds on Linux/Mac …) – you only need a few dlls, no GAC or nothing.
    3. Access to familiar .NET BCL if you’re from there, and you can even access your own code (dlls) if you need as part of the build.

    eg. build script (which I knocked off without much thinking a few months back): https://github.com/kenegozi/mongo-csharp-driver/blob/master/Build.boo
    see the minimal, xcopy (or git clone) dependency in /build folder

    As for the rest:
    TeamCity is awesome. But it is taking a *lot* of memory, and I had to disable my TC server running on my poor 2GB VPS. I’m still looking for something that will leak less memory (damn you Tomcat6) and be generally snappier. Maybe will create one based on Manos one day tailored for my needs (basically execute build script – so no smarts on the server, then get build status report. artifacts, post hooks etc will be handled by the scripts. and with low memory footprint. and zero-conf. and minimal dependencies. and OSS) …

    xUnit/NUnit – I like both. NUnit for it’s wider tool adoption, and xUnit for cuteness.

    I rarely do Code Coverage (I know what are the important parts). I also am not buying into BDD so I have no say on these frameworks.

  2. I’d recommend Jenkins (http://jenkins-ci.org) over Hudson. Jenkins is a fork of Hudson that most of the original developers and community are moved to. It has quite a large following compared to the original Hudson base.

  3. Hi Andrea,

    I’m glad to see you took a look at NSpec. I certainly wish you had nicer things to say ;). I just want to point out that BDD really has grown into two different sets of tools focused on different audiences. NSpec code is not intended to be easy to read by non-developers. However, it’s output should be. Another criticism we’ve heard is that NSpec specs are hard to read even by developers. This is true especially for those unfamiliar with the context/spec (in contrast to gherkin) style. However, everyone who is familiar with and likes RSpec from ruby doesn’t have this problem. Let me know if you have any other questions. Of course, I’d love for you to take a closer look at context/spec and NSpec.

    Thanks,
    Matt

  4. 4 roundcrisis

    Hi Matt:
    Cheers for the comment, and kudos for maintaining an open source tool .
    I ll have a look again 🙂 , maybe write another (more balanced) post with also the good bits about NSpec

    Cheers

    Andrea

  5. 5 roundcrisis

    Hi Ken:

    boo, thats a great idea, never thought about it
    Thanks for the comment

    Andrea

  6. As for CI i would add FinalBuilder
    For Coverage – For people using MSTest, it comes with a bundled coverage tool inside the VS env (I’ve added some msbuild tasks to enable exporting those reports into xml’s for integration with CI systems – http://mstest.codeplex.com/).
    And for BDD you might as well add nBehave – very simple to use, you can write your specification both in plain text and using a C# fluent API


  1. 1 TDD tools for .net developers | Jesus Was Rasta

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: