After a day or two hiatus, we're hopefully back to blogging. Fooberry has a new look and hopefully loads of new content just waiting to pour out to the interwebs.

Since I've stopped blogging there has been a lot of changes. I've left my traditional .Net job and have taken a Ruby developer position at Natron Baxter building games that better the world and its people. A bold claim, but we're trying to make it true. I regret not blogging along my journey, but there's not better time to correct that mistake than the present, but you don't care about this babble anyway. So I'm off.

I've been doing, or trying to do BDD for about a year now. It's been a journey and it feels like after each week I find something I want to do differently. In the past few months, it's been the choice of testing tools.

In The beginning

Similar to most people's experience with testing on the .Net platform, it begins with NUnit, then to xUnit.net. The differences there aren't really that important for this topic. I wasn't doing true BDD, but I was writing BDDish type tests.

    [TestFixture] public When_something_happens {
      public When_something_happens(){
        Given();
        When();
      }

      public void Given(){
        // setup context
      }

      public void When(){
        // what I'm testing
      }

      [Test] public void then_bar_should_happen(){
        // make sure it happened
      }
    }

Now that's not that bad. It works and is sorta BDD. It was good enough to carry us for six months or so.

What's nice about this is it fits into the existing build scripts. We already have Nunit (or xUnit.net) test. We already run them on our CI server and we already report their success or failure. There is nothing more to do.

Cucumber

I've been playing with Ruby, and Rails, for some time and really love Cucumber. Cucumber is really amazing when testing Ruby, and more specifically Rails. There are gems that make setting up test data a snap. It's as beautiful and fun as writing tests are ever going to be...in Ruby.

Now I admit I looked at driving our acceptance tests in Ruby, using Cucumber and RSpec. The thought of using Ruby, or rather more Ruby than Rake, at work was exciting, but it wasn't right for us. Setting up the context in the database was all rework. There had to be a better way.

Cuke4Nuke

Cucumber is great, but didn't fit that well to our .Net environment, but Cuke4Nuke looks to bridge that gap. It would let us write our specs in Gherkin and our steps in NUnit. After some time spent working on the setup, it started to work, but it didn't feel that great. Honestly, I can't remember why, but I didn't really like it.

The most important benefit for us was it got some of our tests in Gherkin.

SpecFlow

We started using SpecFlow a few weeks after using Cuke4Nuke. It's basically the same setup (from my perspective) as Cuke4Nuke. It has specs written in Gherkin and Tests written in NUnit. It was much easier to get up and running.

What I think is the biggest benefit of SpecFlow over Cuke4Nuke was the use of build providers to create the NUnit test fixture file. Why this is so huge is I can be in Visual Studio, smack my keyboard chord to run my tests (or use your favorite GUI tool) and boom. It runs.

Don't get me wrong. I love my command line, but I like that it boils down to an NUnit test. This is also good news for our build server. It is already running and reporting NUnit tests. Nothing more to do.

There are some draw backs to SpecFlow. The steps aren't very DRY.

    [Given(@"a foo exists")]
    public void Given_a_foo_exists(){
      _aFoo = new Foo();
    }

Not that bad, but it does start to be a pain. It uses the regular expression in the method attribute to match against the steps in the feature file. While this redundancy is something I don't like, it also offers a lot of flexibility.

:::java
[Given(@"there (?:are|is) (.*) foo(?:s?)"]
public void Given_foos(int amount){
  _foos = new List<Foo>();
  // add as many as amount
}

What I like is I can now match Given there are 5 foos and Given there is 1 foo with the same statement. This lets the features read more naturally with little redundancy.

StorEvil

StorEvil is the newest testing framework to come to my attention, and they are doing some really amazing things. I am still really new to this tool, so it's best if you watch their screencasts.

What I really like about it is there are no redundancies with the regular expression to match the step definition and the method name. At first I was a little worried they would drop the ability to have parameterized step definitions, but they account for that with special tokens in the method names (e.g. public void Given_there_are_arg0_foos(int amount){}).

But wait! There's more! You don't need to write a step definition for those really simple steps like Then the name should be Bob. How does it work? Watch the screencast. It really is brilliant. I'm not sure this feature will replace all the Then steps. Something like Then the number of foos should be 2 might be more awkward this way that a simple step.

It might be too premature for me to say what I don't like about StorEvil, especially since I haven't played with it yet, but I'll be kind.

It looks like it has its own runner, which means there is some config that goes along with it. This will probably reduce as the tool matures, but SpecFlow fit nicely into my existing tooling, with only me having to say "Here's another NUnit assembly." That's nice. I like how I have tooling that already reruns my NUnit tests when I build, and now I'd have to workout something for StorEvil.

Even though I said the redundancy of SpecFlow's regular expressions was a drawback, it does offer a lot of flexibility while writing tests. StorEvil uses reflection to find it's steps so I would probably end up needing a Given_there_is_1_foo() and Given_there_are_arg0_foos() step. Not that big of a deal since one will just call the other.

It would be nice to write something like this.

:::java
Given(@"there (?:are|is) (.*) foo(?:s?)", () =>
  _foos = new List<Foo>();
  // add them all
  );

You could still find the should steps automagically and skip writing that test. The drawback here is you would need a common base class to get that Given method right on step class. Let's drop all those underscores and look a little more like RSpec.

Overall

I will definitely look into StorEvil and keep my eye on it, but the zero friction of SpecFlow on our current process will keep me using it.

Update

As expected, my ignorance didn't do StorEvil justice. From @davidmfoley:

... StorEvil also has a R# runner and an MSBuild task http://bit.ly/cwryeB Just add StorEvil.TeamCity.DLL to your config (or the Assemblies setting if using the MSBuild task) gives you in-progress test results and trending/etc. reports in TeamCity

After talking with him and reading some more of the documentation, there aren't any reasons I can see to not give it a whirl.

We finally worked auto-encrypting certain sections of our web.config into our build scripts. Nothing is particularly exciting about this, except for the side effect that puzzled me for a while.

We're encrypting using aspnet_regiis.exe like many other people probably are.

aspnet_regiis -pe "connectionStrings" -app "/MyApplication" -prov "MyProvider"

This all works fine and dandy, but after doing so, our redirects stopped working. This makes no sense, but the following section of the web.config is missing.

:::xml
<system.webServer>
<rewrite>
    <rules>
        <rule name="Redirect HTTP to HTTPS"
              stopProcessing="true"
              enabled="#{redirect_to_https}">
        <match url="(.*)"/>
        <conditions>
          <add input="{HTTPS}" pattern="^OFF$"/>
        </conditions>
        <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="SeeOther"/>
      </rule>
    </rules>
  </rewrite>
</system.webServer>

Huh? Every time we run the encryption, this section disappears.

Turns out, we had another system.webServer section in the web.config somewhere. That section remained and this one was cleaned up. Combining these sections works just fine.

Surprisingly, the redirects actually worked before. IIS must find both sections and read them both. I imagine there might be cases were other web.config sections go missing after running that encryption statement.

I'm taking my first real steps into Rails with a pet project. It's exciting and fun and I make a lot of wrong steps along the way. The most recent revolves around routing. Here's a brief bit. I have two models, breweries and beers. (We side project what we love right?) Breweries have many beers, but beers can be viewed on their own. At first, I had my routes laid out like this:

:::ruby
resources :beers
resources :breweries do
  resources :beers
end

That all works well. I can route to /beers/1/beers and /beers. The only problem is the views for beer create links that always go back to the initial /beers route. The new, show, edit, etc. all break out of the route that includes the brewery id. The obvious fix is to just do this in the view.

:::ruby
<%= link_to 'new' , ( params[:brewery_id].nil? ? new_brewery_beer_path : new_beer_path ) %>

That is pretty lame though right? Shouldn't we maybe move that to the helper?

:::ruby
def via_brewery?
  !params[:brewery_id].nil?
end

def new_path
  if via_brewery?
    return new_brewery_beer_path(:brewery_id => params[:brewery_id])
  else
    return new_beer_path
  end
end

Better. Not super lame, but still messy. We still need functions for each type of route and that doesn't feel very DRY. So what to do.

I thought it might be finding that /beers route because it appears first, and maybe if I change that order, things might work better.

:::ruby
resources :breweries do
  resources :beers
end
resources :beers

Well you know what? It does work! It looks through those routes in order. When you're visiting via the /beers route, you don't have a :brewery_id so that first route gets skipped, and we get the second. When we have the id, we get the first route. Now we have a much simpler view.

:::ruby
<%= link_to 'new', :controller => :beers, :action => :new %>

Much much better! The more I use Ruby and Rails, but more I love it. Something like that in .Net would have been much more difficult.

Over the past view days I once again went undercover at a Ruby conference, Ruby Hoedown in Nahsville, Tennessee. I say undercover because I'm not a rubyist by trade, but only as a hobbyist.

The ruby conferences I have been to are in stark contrast to those in the .Net world. The tersest comparison I can come up with is Passion vs Stuff. I don't want to make it sound like Ruby people are passionate and .Net people are all materialistic, because that isn't the case; however the conference content usually aligns to the comparison.

Don't believe me? Here is my impressions of my last .Net Conference.

Here's stuff that just come out. Here is stuff you can use in Visual Studio. Here's some cool stuff. Here's blinking stuff. Here's new stuff. Here's old stuff. Here's stuff in a bag. Here is stuff that is coming out...eventually. Here's demos and demos of stuff....stuff stuff stuff.

So what does a Ruby conference sound like in comparison?

Here's this problem I solved. Here's this pattern I found. Here is this social phenomena I found. Here's why you should care about X. Here is this movement that's really cool.

The list is shorter on purpose because there have been fewer speakers, and fewer attendees at the Ruby conferences than at the .Net ones, but every topic is usually amazing. People talk about ideas they really care about, instead of the tools they bought to fix the problem. If a tool does come up, it's usually by the tool creator and brought up in the context of having a problem, but no tool existed to solve it.

To illustrate the differences in the conference style even more, I cannot imagine having an open signup to give lightning talks at a .Net conference. What would people say? Would anyone even sign up? What are they passionate about? I don't know, but they should be passionate about something or have 10 minutes of something interesting to talk about.

I don't want to write a review of Ruby Hoedown when the conference is only half over, but the keynoter of the first day, Ben Scofield, gave a great talk about achieving excellence. Basically you're either on the pathway to excellence or you've decided to remain adequate. It sounds bad, but trust me it isn't. It perfectly aligns to my comparison of the conference cultures. You're either here because you want to be promoted or you're here because you're still on that path. Both reasons are valid and I'm sure both reasons are represented at either conference.

So here's my call to action, and it's easy. Go to a Ruby conference. You don't have to start coding Ruby and I promise you that you will find the talks, maybe not all of them, relate to your daily work. You'll learn a lot about Ruby. You'll learn that a ton of people actually write tests. You'll meet people from all walks of life. You'll see that slides don't have to have bullet points and screenshots. Most importantly, you will see speeches from people we are really passionate about their craft.