Finally Some Real Improvements For Automated Testing In .NET

5 commentsWritten on October 25th, 2009 by
Categories: testing

As most of you already know, i'm a proponent of unit testing and automated tests in general. There is however one inherent flaw that comes with the unit testing approach: if you didn't think of a problem, you didn't write a test for it, and thus, you're not protected from that problem.

In the past two years we've seen the .NET world gradually accept the concept of TDD, and it has been extended somewhat with the whole BDD thing. However, there hasn't been a single fundamental change which allows you to take away that inherent flaw. Every single variation that has been introduced in the TDD/BDD world is honestly very minor (dare i even say pointless?) because it all boils down to different syntax and slightly different ways of organizing your test fixtures. But again, even if you are doing the very latest flavor of the month when it comes to automated tests, you're still not protected from problems that you didn't think of.

Mark Meyers, a former coworker of mine, has been working hard on porting QuickCheck to .NET and the result is the QuickNet project. Instead of being yet another minor evolutionary step in the automated testing world for .NET, you could actually consider this to be a revolutionary improvement. For the .NET world that is, since other developer communities have adopted this new approach already some time ago.

I highly encourage you to check out what QuickNet is about. I'm about to get much more involved with the project, from a development point of view as well as using it and trying to spread the good word. This is something that actually can offer you substantial benefits over classical unit testing approaches so you really would be doing yourself a huge favor in giving this a shot. Keep in mind that it's still pretty early and that the codebase is still going through some major changes. There is no official release yet, so breaking changes can (and probably will) occur if you already try it out.

There also isn't any official documentation yet either, but Mark has some great posts about QuickNet's usage and there's also a couple of nice examples in the code already. In fact, we also have a few QuickNet tests to test... well... QuickNet itself. Head on over to some or all of the links i put in this post, and start learning :)

« Testability Of Date-Dependent CodePrefixing Instance Fields? »

This entry was posted on Sunday, October 25th, 2009 at 15:27 and is filed under testing. You can subscribe to any comments to this entry via RSS 2.0. You can leave a response, or trackback from your own site.

  • Drew

    You may want to look at Pex if you haven’t already.
    http://research.microsoft.com/en-us/projects/Pex/

  • http://davybrion.com Davy Brion

    it’s not a Pex clone :)

  • http://kilfour.wordpress.com/ kilfour
  • http://hackingon.net Liam McLennan

    You must be wondering why there is such a fuss about BDD, since it is just a “different syntax and slightly different way of organising your test fixtures”. Have you considered that you might be missing the point?

    BDD scenarios are written against features, from the users point of view. TDD tests are written against implementation. It is a different mindsight. Both are appropriate in different scenarios.

  • http://davybrion.com Davy Brion

    @Liam

    i know the difference, but i still think they are _very_ similar… if you can write TDD tests, you can write BDD tests. The point of view differs, but that’s about it.

    And they definitely have their place… the kind of testing that you can do with something like QuickNet would not replace your TDD/BDD tests. Well, at least not all of them but a few of them would make less sense.

Meta

Recent Posts

Categories