James Thigpen

I do BDD with just plain NUnit. I haven’t yet invested the time to mess with any of the frameworks like MSpec or whatever.

I use a ContextSpecification class that I probably ripped off from someone long ago. Everyone in the BDD demos always have fancy reporting though, and I got jealous today so I wrote my own reporting tool.

   1: using System;

   2: using System.Reflection;

   3: using NUnit.Framework;

   4:  

   5: namespace Falcon.Server.Tests

   6: {

   7:     [TestFixture]

   8:     public class ReportGenerator

   9:     {

  10:         [Test]

  11:         [Ignore("Cuz I said so")]

  12:         public void GenerateBddReport()

  13:         {

  14:             var assembly = Assembly.GetExecutingAssembly();

  15:  

  16:             foreach (var type in assembly.GetExportedTypes())

  17:             {

  18:                 if (type.Name.StartsWith("when_"))

  19:                 {

  20:                     Console.WriteLine("{0}:", type.Name.Replace('_', ' '));

  21:                     foreach (var methodInfo in type.GetMethods())

  22:                     {

  23:                         if (methodInfo.Name.StartsWith("should_"))

  24:                         Console.WriteLine("\t{0}", methodInfo.Name.Replace('_', ' '));

  25:                     }

  26:                     Console.WriteLine();

  27:                 }

  28:             }

  29:         }

  30:     }

  31: }

Yup. That’s it.  Reflect over the current assembly, and grab everything that starts with “should_” and “when_” and spray it all over my screen.

Now you could take that and gussy it up with html like some 2-bit floozy, but I see no need. I made it a test that I can just run anytime I want from R# because I didn’t want the weight of some silly assembly/exe file laying around. This was easy.

And it was amazingly valuable.  Getting a report that looks like this:

   1: when daemons are started and stop is called:

   2:     should stop listening for client connections

   3:     should stop listening for bridge connections

   4:     should stop listening for gateway connections

   5:     should raise stopped event

makes it so much easier to find specs that don’t make sense or are bad or whatever.

All in all, I highly recommend running a report such as this now and then to give you a view of what you’re doing.

I am announcing the Ugly Baby Project. It’s a simple thing I’ve decided to do to sort of compare and contrast Ruby on Rails, Django, and Ruby/Merb, and maybe ASP.NET MVC. I’m not sure about ASP.NET MVC. (I’m already familiar with Monorail, and I really don’t know how much more it brings to the table.)

I’m going to implement the same exact small website with the same functionality in all 3 (or 4) platforms.

I decided to pop open a copy of Live Writer and chronicle my first Django first impressions. It’s going to be a bit stream of consciousness. I’m working off this tutorial from Instant Django.

The model creation seems relatively straightforward so far. I haven’t done anything even remotely complicated yet.

I like how the URL routing is so explicit. It does require me to know regular expressions though, which are one of those things I can’t remember for more than 30 seconds at a time. You just map a regular expression of the request to the view that handles it. It’s kind of exactly what I ranted about wanting in a previous post.

Neato. I just got my first “hello world” kind of thing going, but it goes to a database through the ORM and has a model and everything. Took about 40 minutes from first download of instant-django.

So far, I’m pleased. The more I think about how the routing works, the more I like it.  I’m excited about continuin with this.  I’ll keep posting, and include some code snippets once I get something useful going.