First Impressions on Cucumber

Recently I’ve been catching up with the Ruby world again in my limited spare time. I had an idea for a fun little hobby project, but I wanted to actually do it BDD style and in Rails 2. I dug a bit into RSpec again and realized they had a new BDD tool called Cucumber. Seeing there was a beta book out from the prags I paid and downloaded the PDF copy of ‘The RSpec Book: Behavior Driven Development with RSpec, Cucumber, and Friends‘.

Cucumber takes plain text scenarios and runs defined steps to verify the scenarios are working. The idea is Cucumber describes the higher level behavior with more of an outside that application focus and RSpec is used to test the behavior of the individual components. There seems to be some overlap, but it modifies the traditional Red-Green-Refactor into:

  1. Cucumber: Focus on one scenario.
  2. Cucumber: Write failing step definition.
  3. RSpec: Write a failing spec.
  4. RSpec: Get the spec to pass.
  5. RSpec: Refactor.
  6. Cucumber: Refactor.

I worked through the tutorial that involves the classic 70s game MasterMind. (I suspect Dave Astels at work there.) I like the textual description similar to FIT/Fitnesse without so many tables. The feature descriptions are in plain English with a few grammatically important keywords:

Next you take the Given, When, Then, And syntax and build out the steps one at a time diving back and forth into RSpec when you get down to the lower level details.

I find the regular expressions a bit jarring, but just like FIT/Fitnesse this is the code that the business users never see. If your lucky you’re testers can read the code and even key off for ideas to use for exploratory testing ideas. The only other item is I always feel more comfortable just dropping back to an xUnit type testing tool and using good practices to give the tests meaningful names and organize scenario testing appropriately. In some ways you could use just RSpec as well for this purpose. Still I’m forcing myself to use it for a while as any new practice takes some getting used to. Next up is integrating it with Rails.

Compromising Quality for Schedule

I found myself silently cheering for Uncle Bob as he described a recent presentation where the speaker had just about given up on ever getting better code quality, because businesses didn’t value it.

His claim that crappy code is inevitable is based on the notion that crappy code is cheaper than clean code, and that therefore businesses will demand the crap every time. But it has generally not been business that has demanded crappy code. Rather it has been developers who mistakenly thought that the business’ need for speed meant that they had to produce crappy code. Once we, as professional developers, realize that the only way to go fast is to create clean and well designed code, then we will see the business’ need for speed as a demand for high quality code.

Bob Martin

Ken Schwaber makes a similar point that dropping code quality to make a date devalues a core asset of your company, the code base. As a line employee you don’t have the authority to even consider making that decision.

I’ve always found this to be a compelling argument for code quality. If your organization has headed down this path for long your code base is a mess. Sacrificing quality for perceived speed to hit a date is a bad practice. Most of the code base is painful even to look at. Maintenance sucks up your limited developer time. There are hidden costs even with new enhancements since small changes can take weeks as a developer digs into the spaghetti code by hand on code that rarely even has the start of a test harness.

The difficulty of course is this is a common method of operation. The PM informs a developer of some date in the future that they need this new critical enhancement. The developer may bravely say that the date isn’t reasonable. More pressure is applied to find a way to make it work. Well, there might be a way let me get back to you.

The developer sends an email a little later explaining that they’ll do their best and they think they can get the feature done. What they don’t explain is:

  • To get this done in time I’m probably not going to add any tests.
  • I don’t have time to refactor so I’ll probably add more lines to some of the system’s giant classes and mix business logic into the view and controller layer.
  • I may have to work some late hours, I’ll be tired and inject new bugs due to this.
  • I’ll do a bit of manual unit testing and declare it done well enough to push over to QA. In reality I know it has lots of bugs, but I met the date.
  • The next developer who takes on code here will spend even more time trying to figure out the code I added.
  • I met the date, but I feel guilty over once again compromising on my own personal standards of quality.

Here’s to hoping Uncle Bob’s vision wins out.

Ruby On Rails Site Down

I hopped over to http://rubyonrails.org about 7:40pm PST and found this surprise. After a few tries I confirmed it looks like they there’s a real issue. This is decidedly not what I was expecting. Hopefully it’s fixed soon.

Fast Deploy with Groovy Google App Engine

On a whim I setup a Google App Engine account and an hour later I had the hello world Groovy example up and running. They recently added a Java option to the current Python stack. I pulled a quick tutorial from Guillaume Laforge on launching a Groovy web app. A few downloads and a bit of configuration and the app was deployed. Pretty impressive, especially for a free place to do Groovy deploys. The real fun will come when you can just dump Grails apps directly up there.

Back to a Text Editor

Spinning up on Groovy on Grails I pulled down the new 1.1 release. Started up a quick new project in my IDE. Change out my local GRAILS_HOME environment variable and it’s off to the races. After a number of strange errors I realized the IDE wasn’t quite updated to the 1.1 changes. I knew TextMate had Grails and Groovy support. It’s my default editor for Ruby so why not Groovy. It did take a minute to realize the svn repository for TextMate bundles had moved from:

http://macromates.com/svn/Bundles

to

http://svn.textmate.org/trunk/

An open TextMate window, a terminal session and a pretty minimized browser and I can fit everything in a single 17″ window on my MacBook Pro. So far no issues and time spent messing with the IDE. Simplicity is inviting.