Book now


Interview on QCon: BDD, Cucumber and Hexagonal Architectures

I was interviewed recently by QCon’s Peter Bell about various subjects dear to my heart: BDD, Cucumber, Relish and hexagonal architectures.

Click here to watch the video

Agile / Lean Software Development
Hexagonal Rails

Comments (0)


A vision for Cucumber 2.0

At last month’s CukeUp conference, I held a panel discussion between Aslak Hellesoy, Julien Biezemans, Oriol Gual and Jonas Nicklas. I chose these panelists because each of them has written a variation on the original Ruby Cucumber, and I wanted to try to pull these ideas together into a vision for Cucumber 2.0.

This post is a record of that conversation.

Why do we need a new Cucumber?

The current version of Cucumber has been around since 2008, and as Jonas has previously explained the code isn’t much fun to hack on. It’s quite bloated with features, some of which were added as experiments and maybe aren’t used by most users. Carrying this cruft around is holding us back from adding new features that we do want.

Also, the current mechanism for mapping from steps to Ruby code is pretty basic, and doesn’t really encourage the good practices we’ve learned as a community about organising your test code.

What is your vision?

I asked each of the participants what they’d learned from their fork of Cucumber, and what they’d like to see in a new version of Cucumber.

Aslak made three points:

  • It should be possible to use Cucumber as a library, so that other tools can be built on top of it as well as the command-line interface.
  • The way steps are defined in Cucumber-JVM, by simply annotating existing methods, allows you to focus on keeping your test code well organised. We should steal this idea for Cucumber-Ruby.
  • There should be a collaborative web UI for writing Cucumber scenarios with non-technical stakeholders.

Julien added:

  • Integrating the Cucumber-HTML project, which is essentially a web-based client for Cucumber, would be awesome.
  • It would be nice to use the Cucumber-TCK, which is growing into a standard set of specs for any Cucumber implementation.
  • He hasn’t implemented calling steps from step defs in Cucumber-JS, and he’s not sure he wants to.
  • Parallel execution – can we make this possible?

Oriol echoed Aslak’s thoughts about keeping test code better organised: Spinach uses one class per feature, and is generally more object-oriented unlike Cucumber-Ruby’s flat anonymous blocks for step definitions.

Jonas said his goal for Turnip was mainly simplification:

  • He thinks that the reason some people had started to abandon Cucumber was to do with it being perceived as complex.
  • Jumping from plain english steps to Regexps is jarring, and too big a leap in abstraction. 98% of the time you don’t need regular expressions anyway. Turnip uses the concept of placeholders in strings instead to capture arguments.
  • Using RSpec as the runner for Turnip hasn’t worked out so well.

What features should we remove?

It’s always fun making a ‘not’ list, so we brainstormed the current Cucumber features we’d like to kill in a 2.0 release:

Cucumber: Features to Kill

In case you can’t read my scrawl, here’s that list again:

  • Wire protocol
  • Calling steps from step defs
  • Tables (we’re talking about scenario outlines here)
  • DRB / Spork
  • World having everything mixed in, all the time
  • Cucumber.yml
  • Given / When / Then being regarded as the same by Cucumber

As you can see, we got the audience to come up and vote after the session. It looks like nested steps are living on borrowed time!

My view is that with a well-designed core, many of these features can still exist but as plug-ins, thereby allowing people who need them to continue to use them, but without the maintenance burden on the core team.

So what’s next?

Well, I think I have a pretty clear vision for what Cucumber 2.0 would look like. I’d like to start with a simple core library that has no GUI component at all, but can pass the TCK tests. Then we can start building tools around that core, like a console runner, and a websocket server for running cukes from a javascript browser app. I’m personally really excited about where that last idea could lead.

What I’m short on is time. Would it be crazy to ask if there are any companies who would consider sponsoring this project? I can’t imagine a better way to spend the summer than hacking out a brand new shiny Cucumber!

Update: Thanks for the comments, but I don’t find they make a great medium for discussion so I don’t tend to reply to them. If you’d like to discuss this post, please chip in on these threads on the cukes google group.

Agile / Lean Software Development
Ruby Programming

Comments (16)


Bootstrapd – a conference for self-funded startups

I’ve been trying to bootstrap a product for the last year or so; I’ve also got several friends who are either already doing it, or have recognised that it’s a better way to make a living than consulting / contracting for a daily rate. I want to get everyone together so we can swap ideas and experiences, and inspire each other.

So, together with Steve Tooke of Heavies, I’m organising a conference.

It’s a simple, not-for-profit event, to be held in Edinburgh on Wednesday 27th June. More details here:

Agile / Lean Software Development

Comments (0)


Interviewed by RubySource

Last week I had a great chat with Pat Shaughnessy about The Cucumber Book which has been published as an interview on RubySource. Pat really managed to get to the heart of my opinions about how to use Cucumber effectively, so if you’re too busy to read the book, this will give you a good summary of my latest thinking on topics such as:

  • - why Cucumber is pointless unless you involve the whole team
  • - imperative vs declarative style, and why it matters
  • - testing domain objects directly from Cucumber
If you’re using Cucumber or SpecFlow day to day, or considering them and wondering what benefits you’ll get, I think this interview is worth a read.

Agile / Lean Software Development

Comments (1)


Hexagonal Rails – Introduction

A few months ago, development of reached what is a familiar but rather unpleasant plateau for me. Up until that point, it had been developed using conventional Ruby on Rails idioms, with controllers that talk directly to ActiveRecord class methods to make queries, then set instance variables to pass the results of those queries to view templates for rendering. It’s all very procedural, and very tightly coupled.

This post is an introduction to a forthcoming series which will explain how I’ve been tackling this.

Let me start by saying that the coupling in my Rails application is not necessarily a bad thing. In fact, to get the product off the ground and give RSpec’s amazing living documentation a place to call home, we needed to be able to put Relish together very quickly. This is where Rails absolutely dazzles: the early stages of a project are so easy that adding features is a delight.

Unfortunately, the very forces that make adding features to a new Rails application so easy are the same ones that start to hold you back as the number of features grows. That conventional Rails style is what Kent Beck has called a connected design style, Quoting from that article:

In a connected system, elements are highly available to each other (via global state, for example). Adding the first feature to a connected system is cheap. All the resources you need are available. However, the cost of all those connections is that subsequent features are very likely to interact with previous features, driving up the cost of development over time.
The alternative to a connected design style is what Kent calls a modular design style. He contrasts these using this chart:

Cost of Features in Connected and Modular Designs (from

For the first few features, a connected design style is cheaper than a modular design style. In fact, using what might be referred to by software design snobs as ‘poor design’ could give you a competitive advantage in the early stages of your product’s development. The trick is to recognise when it’s time to switch styles.

So, while I love Rails for what it is, I also recognise its weaknesses. To make the Relish codebase habitable in the long term, I need to move beyond its connected design style and establish a more modular design. But how? It’s a question that many different people are asking at the moment, and I’ve been diving deep into what they are saying. Here’s a sample:

For my part, I re-read the outstanding Growing Object-Oriented Software Guided by Tests (GOOS) by Steve Freeman and Nat Price. In that book, Steve and Nat advocate a ports-and-adapters or hexagonal architecture, which keeps your core application logic separate from any technical details needed to connect the application to the real world; technical details like databases, or web user interfaces.

I think it’s easier to use an architecture like this in Java or C#, where packages and interfaces make it easy to see and enforce separation between chunks of the application, than in Ruby where it’s harder to make clear boundaries around areas of the system. But that doesn’t mean it isn’t possible. For the past couple of months I have been experimenting with refactorings in the Relish codebase to move it towards a more hexagonal architectural style. The overall goal is to make the Relish codebase habitable, which for me breaks down into:

1. Fast tests

I never add features without tests, and I want those tests to run fast. The goal of the hexagonal architecture is to have the most interesting (and frequently changing) logic implemented in plain old Ruby objects that have no dependency on any other libraries so they are easy to understand, and can be quickly spun up in a test.

2. Modularity and encapsulation

Ruby is an object-oriented language with great support for functional programming, and I want to make the most of that to keep Relish’s code easy to change.

3. Clean and well-organised

I want a structure that communicates what each part of the system is doing, and makes it easy for new team members to jump in and start hacking on the code.

I’ll start the series by explaining a couple of key concepts from Steve and Nat’s GOOS book, and about hexagonal architectures in general. Then we’ll get down to some practical work refactoring a typical Rails controller. Stay tuned!

Agile / Lean Software Development
Hexagonal Rails
Ruby Programming

Comments (6)