Monthly Archives: February 2015

Cucumber Testing Notes and Tips

I’ve just finished reading The Cucumber Book, which is the best text book I have ever read, and I have had to read a lot of textbooks. I actually didn’t even think I could enjoy a text book before this.

I might have enjoyed it so much because I had been kind of teaching myself how to do Cucumbers anyway for a little while, so it wasn’t all totally new to me, which meant I could absorb the lessons a lot better.

After reading it cover to cover, I have assembled a list of the advice I found the most useful in the book. I include page numbers so I can remember the places for the advice, but if you have the book, you can play along too!

  • Use scenario outlines combined with data tables to run repetitive scenarios with varying values (pg 70)
  • Use Backgrounds, for repetitive beginning steps (e.g. Given a user has logged in)
  • Use a capture group to pass a value/word through into your step (pg 206)
  • Introduce a culture of writing tests for bugs (pg 224)
  • Run code coverage reports (pg 227)
  • You can use Guard or Watchr to run cukes in the background whenever you update your code
  • You can use Relish to publish your cucumbers as documentation for your code
  • Use Cucumber Transforms methods to reduce repetitive actions on inputs
  • Tags you can use to prioritise tests: ones that often fail; ones that are important features
  • $cucumber --format usage will show which steps are unused
Leave a reply

Truncation vs Transaction in Cucumber Tests

When you are running Cucumber tests, you can ‘clean’ your database between scenarios using either a truncation or transaction strategy. It took me a little while to get my head around this completely…but this is it:


If you choose truncation, Cucumber uses a Before hook to start a database transaction just before your scenario starts. This transaction is never committed, it is just rolled back at the end of the scenario, leaving your Database unchanged.

Database transactions are isolated. Whatever happens inside a transaction cannot be seen by any other database connection.

So if you have an application that will use more than one database connection, i.e. a different database connection than cucumber, then you can’t use the transaction method.

When you use a browser action to insert data to a database, the Cucumber database can’t see it. And if you use Cucumber to change the database, the database of the webdriver can’t see it.


This is slower than the transaction method. Unlike transactions, which pretend nothing has happened and leaves your database in it’s original state, truncation will delete all the data in your table.

You need to use truncation in multithreaded environments.

Leave a reply

Testing CSS/jQuery/Capybara Selectors With Pry

Running Cucumber tests over and over to try and get the selectors just right can be tedious, especially if enabling Javascript which requires fixtures to be loaded first! To make it easier, I recommend using the Pry gem.

Put the Pry gem in your code to get runtime debugging that can also help with identifying selectors. I thought Pry was great for telling things like what values variables have at different times in your programme, but I discovered it was also awesome to help figure out Capybara selectors while running my Cucumber tests.

When my tests say “Can’t find selector blah blah blah”, I can put binding.pry in the code, run my tests, and when it hits binding.pry it will stop the programme and I can start putting in my capybara instructions, like; find, within, click_on, click, etc.

By testing in the console like that, it is much quicker than running my tests over and over again. Sometimes I get carried away and just keep going and going in the console, typing out all of the steps I need to do next…and next..and next…

Leave a reply

Ruby Conf AU 2015

rubyconf 2015

As part of Rails Girls Summer of Code, I was given a free conference ticket to Ruby Conf 2015. I spent some of last week there, and it was hands down the best conference I have been to (on any topic).

It had something to do with the amazing venue (Federation Square, Deakin Edge theatre), the great after-hours social events (parties, roof top cinema) and also that a lot of my friends attended, making it so much fun.

But, on the serious side of things, there were also fantastic talks. They were pitched at all different levels, so that there were things for everyone, and they were also on a broad range of topics; technical, career, soft skills and inspirational ‘look what I made’ talks. There seemed to be a particular focus, by a number of speakers, on Service Oriented Architecture.

Below is an outline of some of the talks (using my own categorisation).

Continue reading

Leave a reply