Keynote

Aslak Hellesøy

• Aslak described the components of cucumber, namely Gherkin, Aruba, Cucumber and Cucumber-Rails.
  I hadn’t realised that Aruba, which is used for testing command-line programs with cucumber, is actually used by the Cucumber features themselves.
• Cucumber has overtaken Fitnesse in terms of downloads
• Various documentation sources were mentioned: the cucumber wiki, the cucumber relish pages, Secret Ninja Cucumber Scrolls, and there is also a PragProg Cucumber book in progress.
• The future roadmap of cucumber was interesting – Cuke4Duke will be replaced with a proper redesign and rewrite of cucumber in java (to be called Cucumber.java). The design of Cucumber.java will actually prompt a rewrite of the ruby cucumber, reducing the size of the codebase significantly
• There is also an online web-based editor for cucumber in progress, based on ACE, which is available to try now.

What Makes a Good Feature File

David De Florinier and Gojko Adzic

The main points I took out of this session were:

• Cucumber features should be specifications, not scripts
• Gojko’s blog has articles on writing cucumber features

Wip, Kanban, whole-team BDD

Perryn Fowler

• I liked Perryn’s idea of “Kanban Dots” for limiting WIP – basically blue dot stickers you put on your kanban wall, and you are only allowed to put cards next to dots.
• Traditionally, in lean manufacturing, WIP limits helped reduce the amount of storage space needed. I liked the analogy for lean software development, where WIP limits help reduce the amount of “head space” required.
• For whole-team BDD, an initial cut of the feature (or ‘cuke’) should be written at the analysis stage, for the customer.
• The customer should be shown the cukes when the development is complete, at the showcase stage
• It is possible to use cucumber to police WIP limits – e.g. using the config --tags @wip[2] --wip will fail the build if there are more than 2 wip features
• Perryn did mention using “Flows” and “Mechanics” – where a flow is a high level scenario, and a mechanic is a more detailed scenario. There wasn’t much detail on this, other than that Relish might support this kind of pattern in the future.

Deliberate Discovery

Dan North and Elizabeth Keogh

This talk is well worth watching – it provides lots to think about.

• Ignorance is the biggest constraint in a software project
• If you were going to redo a project from scratch, it would generally take much less to do the second time around
• Assume ignorance, and second order ignorance (you don’t know what you don’t know)
• Options have value – sometimes it is wise not to commit to a certain option too early
• Get all stakeholders together at the beginning, to avoid “oh crap” moments further down the line, where you discover you’ve chosen the wrong option
• Prioritise by ignorance – i.e. the areas you know least about
• Create a learning environment – missing an opportunity to learn is waste.

CukeSalad

Antony Marcano

• Anthony’s blog
• CukeSalad on github
• CukeSalad tries to solve the fact that acceptance tests are often too low-level – they describe the actual interactions with the webpage, or API
• CukeSalad has Goals (what the feature is trying to achieve), Tasks (stages to achieving the goal), and Actions (the interactions required to complete the task)
• CukeSalad allows you to write one set of features, and then use them with different adaptors to test, for example, your GUI, CLI, API
• Attempts to help with: wordsmithing of scenarios, organisation and reuse of steps, maintenance of steps.

Cucumber-Chef

Stephen Nelson-Smith

The cucumber-chef project allows you to test your chef scripts that spin up large numbers of servers. The project uses LXC (linux containers), so you can run one ec2 instance, and then use multiple LXCs – which is cheaper and faster than spinning up large numbers of ec2 instances just for testing.

At the time of writing, the gem was not available – but it should appear on github soon.

SongKick

Joseph Wilk

• check out Joseph’s blog
• Songkick found Gherkin was not good for user-experience testing – they generally had hand-drawn diagrams attached to features to show what it would look like
• Publishing your cukes (e.g. relish) helps stop the steps being developer-centric
• Abstract your steps using something like CukeSalad or Page Model
• Songkick tried using testjour to distribute their tests onto multiple machines, and speed up the build – rails projects should use hydra for this (there wasn’t much detail on this)

Here’s the list of recommendations we came up with:

Cucumber Feature Tests

• Don’t change generated step definition files (e.g. web_steps.rb from webrat), instead add new steps to new files.
• Extract common steps (ones used in more than one project) to a template

WebMock

• Use webmock instead of FakeTTP. We seems to have occasional problems with FakeTTP.

Template

• Use a template for common stuff such as Capistrano Tasks, Rake Tasks, Scripts and Cucumber Step Definitions – as well as the usual initial project setup

Configuration

• Instead of using constants in production.rb, use a configuration class.

Continuous Integration

• Have tests that test installing from scratch
• Have tests that test upgrades
• Have a test that uses the latest versions of gems

(you can never have too many tests).

Deployment

• Use git-deploy instead of just capistrano – it’s faster, easier, and uses the power of git

REST

• Use Restfulie