pik, IronRuby, MRI, and a .Net Project

On a recent ASP.Net MVC project I was leveraging IronRuby and Cucumber to get some BDD specs in place to drive development. Though this post isn't about the benefits of BDD, it was very easy to get the specs worked out with my Product Owner, and the demos went really quickly. For the most part, I was using IronRuby to run functional tests at the controller level.

Then we decided to add on some GUI tests. With Ruby and Cucumber already in place, we decided to give watir a try. Except once we went on to using watir, IronRuby was no longer needed to test the website. We could instead use MRI 1.9.2 as our interpreter and get a little more speed out of our watir tests, and leverage the latest version Cucumber.

Since we're doing our development in Windows we don't have the luxury of RVM, but pik is a great solution to switching Ruby interpreters on Windows. During development, a few pik switch statements keeps all our cucumber tests in sync with either our IronRuby testing or our watir testing. However, if we wanted to run them all at once I had to write a little batch file to handle it. (I'm a dev, I'm lazy, I just want to type one line in the command prompt and have it all kick off...)

After knocking the rust off my batch file fu, here is the contents of that batch file...

@echo off

@call pik sw 100

@call rake

@call pik sw 192

@call rake watir

Here's what's happening in our little five line helper file. First line just doesn't echo your commands back out to the command prompt. After that we call pik sw 100, which is pik switch to IronRuby 1.0.0. Then our default rake task is called, which builds the project, runs the unit test suite (in nUnit in this case), then run the IronRuby cucumber tests. pik sw 192 is switching to Ruby 1.9.2, then calling rake watir just runs our watir tests against the already built website. Pretty straightforward.

Now that was only for our dev machines in order to do one line build test, test, test during development. Our CI server was much easier to configure.

We were using TeamCity as our CI environment when we added watir to the mix, but the batch file wasn't needed as TC allows for different build tasks to use rake and specify which interpreter to use. So it was as easy as add an IronRuby build task call the default rake task, then create another rake build task and call the watir task in the rake file. We have since switched from TeamCity to Jenkins, but the set up with a build task per interpreter is identical.

(Don't have pik installed and you're a Windows using, Ruby loving programmer? Ben Hall's post on getting pik installed and running is the best reference I've found.)

IronRuby: Rake, Albacore, and you

In my post about setting up to run Cucumber with IronRuby, I included steps to install Rake and Albacore, but didn’t use them. In this post, we’ll put them to use.

Using Rake in .Net isn’t really a new idea, and a number of people have been using it for a while. I’ve used rake to compile and run the tests on all my .Net projects for at least the last year. Before Albacore came along to make my Rake tasks easier, I was copying the set-up from the folks at Fluent nHibernate. (FNH has used rake to build as far back as I can remember it existing and is now utilizing Albacore as well.) Now with IronRuby in the mix, rake is going to take on even more fun in your .Net projects.

For my example I’m again going to use my TestingSeaPound project, and specifically the rake file I’m using in that project. Pop it open real quick, and we’ll look through it.

At the top, you’ll see the standard Ruby require statements. In this file we’re including rake, the task library for RSpec, Cucumber, the task library for Cucumber, and Albacore.

Following the required libraries are a number of tasks that are combining the tasks that are defined later in the file. This is a way keep your rake file nice and dry. Define each task as needed, combine them in a call such as task :spec => [:msbuild, :rspec] to reuse them in different situations. From the command line in the directory where this rake file lives, if I enter “rake spec” it’s going to build the code then run RSpec

The only task in this list to take note of is the :default task. That’s the task that will run if you’re at the command prompt and just enter the command “rake”.

MSBuild

Skip down to the line that includes msbuild do |msb|. That’s our first task definition, and in this case we’re using the Albacore library. The top line of that task that includes the path_to_command is needed to build a .Net 4.0 project. I believe a fix is in the works, and may already be in place, but when I set up this file this was the way to call the .Net 4.0 compiler.

The next two lines, properties and targets, should look pretty familiar to anybody who has set up a .Net build in the past using MSBuild or Nant. Here we’re just saying what configuration we want to compile in, and what our target build is. Following that I’m setting the verbosity to quiet to keep the command line output fairly small.

The last line should be fairly obvious, it’s the path the solution file. Since MSBuild is very good at picking up a solution file and building it, why fight it? Pass the solution to MSBUild and let it do its thing.

nUnit

The next task down is our nUnit test runner. This is again an Albacore task, and it’s just pointing the test assemblies at the nUnit console app.

These two tasks are the only Albacore tasks in the file, so here’s as good a place as any to let you know the magic going on under the covers with Albacore. It is in essence building the correct command line arguments for MSBuild and nUnit and then shelling out to run them. Now, there’s more work going on than just that, but that’s the bulk of if. Albacore is giving us a nice DSL to write .Net build tasks. I’m only using two, there are a lot more available.

One important note: to this point our rake file hasn’t required IronRuby. You can use Albacore to build your project and run .Net based testing suites with MRI, IronRuby isn’t a requirement. I know as a .Netter that may seem odd, but we’re really not leveraging the Iron part of IronRuby.

Yet…

RSpec

The next two tasks are both RSpec tasks, and they’re running rspec against our .Net app. The first task is the default runner where it outputs a period for each passing test, the second will output the describe blocks and spec names.

NOW we need IronRuby. Not so much for the rake task, but because RSpec isn’t going to be able to test our dlls without the Iron added to our Ruby.

Cucumber

The final two tasks are Cucumber tasks. The first outputs the standard cucumber output, with each feature and specification output in their full glory – minus line numbers because I turned those off with the –-no-source option. The second task outputs the cucumber specs very much like nUnit and RSpec do, with a period for each passing test.

Once again we need IronRuby. Since I’m using the Ruby version of Cucumber in this case, we need to add the Iron to get it to reach into our dlls and do its magic.

That’s all for the tasks required to build and run the tests for this sample application. If you pull down the code and go to the root of the project and enter “rake all” at a command prompt, you’ll build it and run each suite of tests in order. Give it a try.

IronRuby: 0 to Cucumber in 15 minutes

Once again, a 140 character (or less) “outburst” gets me in trouble with a follower and I end up with a blog post. This one is one I probably should  have written a while back. I’ve enjoyed working with IronRuby the last few months, so this little intro is long overdue.

First things first, you’ll need to install IronRuby. Head off to the download page, and click on your msi of choice and let the installer do its thing.

Since my goal here was to get cucumber ready to roll against some .Net assemblies, you’ll need to install a few gems. IronRuby comes with Ruby Gems already installed, so thankfully to install the ones you need you just need to type ‘igem install’ a few times.

“Wait, what? igem? WTF?” Yeah, that’s one of the IronRuby-isms, putting an i on the front of a couple of commands. If you’ve done a bit of Ruby, you’ll have a little muscle memory to retrain, but it’s a small hurdle. (You’ll also type ‘ir’ instead of ‘ruby’ to run a script and ‘iirb’ instead of ‘irb’ to get to irb.)

So, on with our gem installing…

igem install rake

First install is rake. I’m not going to use it right away on the cucumber running, but I’ll use it at some point, I always do.

igem install albacore

Like rake, I’m not going to use this one right away, but I’ve found it to be the one must have gem if you’re using rake with your .Net builds and test runners. It just makes you life that much easier.

igem install rspec

I’m not starting out writing rspec in this example, but cucumber is going to use its matchers.

igem install cucumber –-version “=0.6.4”

This is the one we’re after for this example. Be sure to add that version command on there because IronRuby isn’t quite ready for the latest version of Cucumber. But, 0.6.4 is going to get the job done for us.

igem install iron-term-ansicolor

The first time you run cucumber, it’s going to advise you to install this gem to get color coding in the terminal window. Go ahead and do it now, and you skip that warning. (Or don’t, and check the message for yourself. ;) )

Now all you need is some features, some step definitions, and a dll to write it all against. As luck would have it, I have just that written up in a code sample that I just used at Codestock a couple weeks ago. (And also coming soon to an Ohio user group meeting near you…) Here’s the root of that project: http://github.com/timwingfield/TestingSeaPound

The features directory there is where you’ll find my cucumber samples and the dll they are running against. Download it and give it a shot. Once you get it downloaded, open the command prompt in whatever directory contains the features directory (not the actual features directory) and type:

cucumber features

Happy IronRubying!