Cucumber running headless Selenium with Jenkins (the easy way)

Selenium is a great way to test your javascript from Cucumber. It opens up a browser and you actually see it clicking around, filling in fields and submitting forms right before your eyes. It’s cool.

Jenkins is a brilliant continuous integration and deployment tool. I recently set it up for a new project i’ve started. It checks for git commits, pulls the latest code, runs all the specs and cucumber scenarios, and if they all pass, it deploys the code to five different websites. It’s great because we just have to git push and all five websites will get updated.

But Jenkins runs all its commands on the command line, and it doesn’t actually have a display on which it can run a browser. This isn’t too big a problem. You can use Xvfb virtual frame buffer which can emulate a display for you.

The old way to do this was to configure Xvfb to make a display (we usually use 99 to avoid conflicts) and write little shell scripts to start and stop this display, and export an environment variable to make sure the display is used ………… YAWN!

Now enter the gem headless. It does all those boring things behind the scenes, making it much simpler. I got this tip from 8th light’s blog post Jenkins, RVM, and Selenium. To get headless Selenium you simply have to do the following:

Install Xvfb:

sudo apt-get install xvfb

Require headless in your Gemfile:

gem 'headless'

Add this little snippet to features/support/env.rb:

if ENV['HEADLESS'] == 'true'
  require 'headless'

  headless = Headless.new
  headless.start

  at_exit do
    headless.destroy
  end
end

Tag your cucumber scenarios with @javascript for those that require selenium.

Call cucumber like this:

HEADLESS=true cucumber

It Just Works™!

As an added bonus, when i’m working remotely i’m often tunelling via SSH to a shared screen on a remote server. I can use the same HEADLESS=true trick to run my selenium scenarios remotely.

Exposing my ignorance

I have been encouraging my apprentice Rohit to blog about ignorance. It’s great to talk about what you know, and what you can do well, but for people to really trust you it’s important also to be honest about what you don’t know yet, and what you’re looking to learn.

As software crafters learning is part of what we do. There is always more to learn; it never stops. Personally i really enjoy learning. I love the feeling of new information going in and being absorbed.

Since i asked Ro to blog about exposing ignorance, i thought i should do the same. It’s good to start with a review of where you are now.

Where i am now

It’s fair to say my strongest language is Ruby. I’ve been programming in Ruby for about 5 years, i’ve seen my style grow and change a lot. I feel very confident in domain modelling and object orientation using Ruby.

I’m pretty confident with behaviour driven development for Ruby, using Cucumber and Rspec. I know a lot about Rails and a fair amount about Sinatra. I am comfortable using MySQL, PostgreSQL and MongoDB.

Exposing my ignorance

My biggest weakness at the moment is in having only one strong language. And here is where i expose my ignorance. I know a bit about a few other languages, but i’m not where i want to be. I feel embarrassed when people talk about Java, Haskell, Scala, Io, and i am unable to contribute due to my lack of knowledge.

Confronting my ignorance

Since thinking about this blog post, i have already begun confronting my ignorance: my first step was to contact Joel Gascoigne who develops Buffer – a simple tool for scheduling tweets. I wanted an easier way to use Buffer on my phone, so i offered to make an Android app. I saw this as a pet project to get me learning a bit more about Android development in Java.

The app is open source; you can check it out on github.com/bufferapp/Android. A simple working version is now available in the Android Market: Buffer for Android.

We have a few ideas for moving the app forward, but for now i’m happy that we’ve got something out there that works, and it has given me the confidence to develop more Android apps.

My next tactic will be to study the book Seven Languages in Seven Weeks: A pragmatic guide to learning programming languages, by Bruce A. Tate. This is an intensive study of Ruby, Io, Prolog, Scala, Erlang, Clojure and Haskell. By learning how to solve a non-trivial problem in each of these languages, we learn the unique strengths and weaknesses of each language.

I’m looking for other people to study along with me, so if you’re interested, let me know!

Once i’ve studied those seven languages, i want to learn some Python. I’ve been hearing a lot about Python lately, and it seems like a language i really want to know. I already have the book Learning Python by Mark Lutz and i look forward to getting to that.

So that’s me: i have listed my strengths, exposed my ignorance and outlined how i am confronting it to improve myself and learn more. What about you?

How BDD focusses on the ‘why’

Today i got talking with somebody who was unconvinced of the benefits of behaviour driven development. I hope i’m not misquoting them, but they seemed to be saying that BDD doesn’t tell you why something happens, only what happens.

This person also said that BDD doesn’t encourage you to code correctly. That i agree with. You can code poorly with any test tools or development framework. The only thing that’s going to encourage you to code cleanly is your own standards, or those that are instilled into you by requirement, or pair programming, or code review.

To me, the focus on the why is a key difference of BDD as opposed to TDD. Here’s an example for comparison:

Test First Development tells you that you’re going to use an Array of names and it’s going to receive the shuffle method. You write the test because you’ve already decided that’s what you’re going to do. It is brittle because a change in the code will require you to rewrite the test.

Test Driven Development says that somehow some names are going to be input, and after the process they’ll come out in a random order. It doesn’t necessarily mind whether you use an Array, Hash, a shuffle method or write your own randomising function. You let the tests drive you to make those decisions when you need to.

Behaviour Driven Development tells you about me as a key stakeholder, and that i want to draw names in a random order, so that i can assign prizes fairly. It tells a story about the people entering, explaining in natural language that the names are drawn out of a hat, and when they are, the first randomly chosen person picked gets the first prize, and their name is put aside so that they don’t win another prize. How you implement the details to achieve this behaviour is entirely up to you as a developer. But you should understand quite well what you’re expecting to achieve, and why.

Okay, i know, it’s a horrible example because it’s quite difficult to test for randomness. Given an unbiased coin / When i flip the coin / Then i should get … either heads or tails … Anyway, hopefully those examples show how i consider the test methodologies to differ.

My mentor Enrique recently helped me to understand BDD, particularly Cucumber scenarios, as documentation of the understanding between the client and the developer. It just so happens that you can execute this documentation to help you write your code, and continue to use it for regression testing.

Now i pass over to you, my readers! Are your opinions different from mine? What have i missed out, misunderstood, or misrepresented? I’m not an expert here! Fortunately, you don’t need to be a BDD expert to benefit from using it! :)

Celebrating a fantastic Code Retreat day

Today, Saturday 7th May 2011, there were six code retreats around the world! They were in Belgium, Spain, UK, USA, and two in Romania! We all did the same challenge: implementing Conway’s Game of Life in pairs, using test-driven development, in iterations of 45 minutes, discarding code at the end of every iteration and pairing with somebody different for the next iteration. We introduced a few extra challenges in every session! ;)

I co-facilitated the code retreat at Sheffield University. We had 18 participants: a good mix of computer science students, professional programmers, people who code for fun, and someone who seemed to have been dragged along but got thoroughly stuck into solving the problem along with everyone else! :)

Tom Crayford co-facilitated with me, and Chris Murray ran around making sure everything went extremely smoothly.

In iteration 1 we gave everyone chance to explore the problem without heckling to see how they would do. The only special challenge was to pair with someone they didn’t know. In the retrospective we talked about the languages and classes used.

For iteration 2 we talked about TDD as in, letting the tests really drive the code in the direction they want to go. We challenged people to do the very simplest thing they could possibly do at each stage. Many people found themselves writing unnecessary code, so we kept bringing them back to the rules of the game. The retrospective brought up questions of where to start, and whether a cell should be responsible for its own state, or whether a separate entity should know where all the cells are.

In iteration 3 we encouraged people to try a different starting point, to see how that worked. We stipulated that the code could not contain any booleans, like true or false or strings or numbers representing boolean states. The third iteration was sneakily only 30 minutes long, which we didn’t tell anyone until after the retrospective! There was a good discussion about using a grid to hold the cells, versus having an array of cells who know their coordinate position.

Throughout the day, at various points, we were able to have Skype video calls with other code retreats. We found this very enjoyable: we discussed the different implementation options with other people who were also tackling the same problems. During the day, Sheffield managed to communicate with all the other code retreats: Valladolid in Spain, Cronos in Belgium, Bucharest and Timisoara in Romania, and finally, towards the end of our day, Pittsburgh in Pennsylvania, USA, just as they were at the end of their second iteration.

We also had two projectors constantly showing the twitter #coderetreat hashtag on tweetviz.com and a slideshow of pictures on hashalbum.com. These things really helped us to feel connected to a bigger community of people sharing a similar experience at the same time.

After lunch we introduced Keith Braithwaite’s TDD as if you meant it and for iteration 4 we challenged people to obey the strict structure given. The purpose of this was to really break everyone’s normal processes to avoid mental shortcuts. It really ensures that the solution is exactly what the tests require, and nothing more. It was a tough challenge but it was taken well. A lot of people found they came to a better solution when these restrictions were applied.

In iteration 5 nobody was allowed to use if statements. (Or case statements, ternary operators, etc.) We also focussed on ping pong pair programming. This is where one person writes the test, the other person writes just enough code to make it pass, then writes the next test and hands back. During the day i had seen a lot of rather uneven pairing, where one person was doing most of the work, and the other was mostly just watching and commenting. Ping pong helps to address that by bouncing back equally between the two. Comments in the retrospective were that you had to concentrate harder, and felt more engaged because of it. I was surprised that many people had not paired that way before.

Iteration 6 was the last one for us. (Unlike Valladolid who went on to 8 iterations!) We gave people a bit longer and told them to just enjoy this one. The restrictions were that no method could be more than 3 lines long, and the code you wrote had to be the best you could possibly do. You had to write something you could be totally proud of. For most people, they said their code wasn’t the best they could possibly do, but they were definitely proud of it! :)

At the end of the day we did a raffle. Entry to the raffle was by way of a donation to Bletchley Park, for which we raised £200. Names were shuffled in a Ruby array and winners received either a copy of Apprenticeship Patterns or a software craftsmanship motivational calendar.

With that done, all that was left was a trip to the pub to relax after a good day’s work! :D

Thanks and kisses

I thank Tom for being a fantastic co-facilitator, and Chris for doing an excellent job of organising everything: food, refreshments, sponsorship, venue, my hotel last night, and probably a whole lot more that went so smoothly it was unnoticed.

Thank you very much indeed to the sponsors and supporters: epiGenesys, University of Sheffield Enterprise, O’Reilly UK and The GIST Foundation. It would have not been nearly as awesome without your help.

Thanks to all the people around the world who talked to us over Skype – it was great to feel part of something so much bigger than just us.

Thank you so very much to everybody who participated today. You really made it a great day for everyone.

Pretty autospec growl messages

It’s interesting how you can sometimes notice something through someone else’s eyes that you’d previously overlooked. This week i have been mostly working with my apprentice Despo on a Rails project. Despo noticed that running specs in Rails takes a long time to initialize, which something i am well aware of but i guess i’ve sort of got used to it.

So we decided to do something about it. The first thing we did was set up Spork. If you want to know how to do that i recommend this post by Chris: How to get Spork working NOW on Rails 3, Rspec 2 and Cucumber.

As Chris mentioned at the end of that post, autotest and autotest-growl play well with Spork, so that is what we did next. The results can be quite nice!

Autotest notices which files have changed and starts running the relevant specs:

Growl can be configured to show failure messages in red:

Success messages are shown in green:

Growl can also show when specs are pending:

How did we achieve this?

Firstly you will need to install the gems autotest and autotest-growl. Either include them in a bundle, or install them system-wide if you want to use them across all projects.

If you use RVM for different versions of ruby you might find this command useful:

for version in $(rvm list strings); do rvm use $version@global && gem install autotest && gem install autotest-growl; done

Secondly you will need a .autotest file. You can either put it in your project’s root directory, or in your home directory ~/.autotest

Here is mine so you can see what it looks like:

#!/usr/bin/env ruby
require 'rubygems'
require 'autotest/growl'

Autotest::Growl::image_dir = File.join(ENV['HOME'], '.autotest_images')
Autotest::Growl::show_modified_files = true

Autotest.add_hook :initialize do |autotest|
  %w(.git .DS_Store db log tmp).each do |exception|
    autotest.add_exception(exception)
  end
  autotest.order = :random
end

Thirdly you will need to install Growl and configure it to your liking. I have mine set to Music Video because it’s so impossible to miss!

The only trouble with the Music Video style is it can only display one message at a time, so i make it fade in and last for just 1 second. Happily, with growl colouring, you don’t really need to read the message – the colour tells you immediately what happened.

The colours you need to set are:

• Very Low for passed
• Moderate for pending
• Normal for info
• Emergency for failed (or syntax error)

Here is my Growl configuration:

Finally, if you want cute pictures to come up with your growl messages, you simply need to put them in ~/.autotest_images – named passed.png, pending.png, info.png, failed.png and error.png.

Running autotest

Now, of course, you need to know how to run it!

With Rails 3 you need

AUTOFEATURE=true autotest

With Rails 2 it’s

AUTOFEATURE=true autospec

If you only want to run specs and not features, just take away the AUTOFEATURE=true bit.

But what about FSEvent?

The normal behaviour for autotest is to constantly poll your filesystem looking for changes. This is wasteful as it will use a lot of CPU and drain your battery, but there is an alternative. From Mac OSX 10.5 onwards an FSEvent service reports modified files.

To make use of FSEvent, you should be able to just install the autotest-fsevent gem and require 'autotest/fsevent' in your .autotest file.

Unfortunately, when i tried it, the mere presence of the autotest-fsevent gem seems to cause the specs not to run. It notices changes but doesn’t do anything about them. So if anyone can help me to understand what’s up with that, i would be grateful!

In the mean time, i’m just trying to remember to stop autotest whenever i’ve finished using it.

Welcome to Alberto Peña!

Last week eden were delighted to receive Alberto Peña as our newest intern. Alberto is a Java programmer from Spain, who has taken a leap of faith by coming to intern at eden, setting aside the comforts of a job, girlfriend, culture and language in order to experience something new. For this, i admire and respect Alberto very much.

In the first week we set a deliberately impossible challenge for Alberto: to implement rfc2616 – the HTTP server/client protocol. We stipulated that it must be developed with BDD using Cucumber and Rspec. On Friday Alberto gave a presentation of the first week’s work: a demonstration of the successful GET request. Alberto walked us through the code explaining how it works, and talked about the challenges and decisions faced during the week.

Alberto has been blogging every day, and it’s really interesting to read about life at eden seen through somebody else’s eyes. I encourage you to follow Alberto’s blog: El Programador Feliz. It’s mostly in Spanish, but if you’re not completely comfortable reading Spanish, Google Chrome should automatically offer to translate it for you.

Alberto is not being paid during this internship at eden, but there is a pledgie page in case you wish to make a donation (which goes directly to Alberto) – Help an aspiring craftsman on his journey.

Welcome, Alberto! It is a real pleasure to have you with us!

The Minisculus Challenge – Winner Announced!

On Friday 7th October, at Software Craftsmanship 2010, eden announced Minisculus – a series of encoding, decoding and code breaking challenges, loosely based on the historic challenges faced during the second world war.

Minisculus was set by Steve and Todd. I took the challenge in the week before SC2010 and really enjoyed it. There is enormous satisfaction in figuring out the answer, posting it to the server, and if you got it right, receiving the secret URL to the next question. The progression of the challenge provides new insights and plenty of opportunities for refactoring to keep your code clean and simple.

We ran Minisculus as a competition for a £100 Amazon voucher. We had 12 entries; most written in Ruby, but also including solutions in Java, Clojure, PHP and Python. It is fascinating to see the different ways that people implemented their solutions.

Our winner is Luke Redpath, who is a freelance Ruby and iPhone developer in London. Luke wrote the solution in Ruby, nicely specified using RSpec. The code is particularly clean, easy to read, well refactored to be very simple. Luke has good use of object orientation, using a ShiftCypher that can accept any number of wheels, which have their own configurations for encoding and decoding, a great example of the Strategy Pattern. Luke also included a code breaker using keyword matching, and automated the communication with the Minisculus server to send answers and receive the next question.

Luke’s was also one of the first entries we received, and a nice little touch helped seal it for Luke: the inclusion of a MarkIII machine that raises an exception when called: “Not Implemented due to budget overruns!” – a joke that shows the attention paid to the story told by the challenge. Have a look at Luke’s code at github.com/lukeredpath/minisculus.

You can see a Hall of Fame on the Minisculus website, showing everybody who completed the challenge, including source code for many of the entries.

Although the competition is now over, the challenge remains for anyone who wants to try it! Thanks to everyone for participating so far!

minisculus.edendevelopment.co.uk

Code Retreat in Winchester

All day today there was a Code Retreat at Eden Development. About 20 people came, from all over the country, and we spent an excellent Saturday pair programming together, sharing ideas, having stimulating conversations and getting to know each other much better.

At a code retreat everybody works on a single problem: Conway’s Game of Life. You pair with different people in each 45 minute session. You have to TDD the development, but you can use whichever programming language you choose as a pair. At the end of each session all the code must be deleted. You do a retrospective as a group, have a little break, then go and pair with somebody else.

We got through 6 sessions, which means i pair programmed with 6 people i didn’t know very well before today. It was great! The first two sessions i paired with Paul and then Quentin. To start with, we were pretty much feeling our way through the problem, implementing the rules of the game, and then getting stuck with determining the position of each cell.

In the third session i paired with Ben and we decided to try a completely different approach: dealing purely with coordinates to represent the positions of live cells. It actually worked quite nicely, although implementing the rule logic became quite difficult.

After lunch we were invited to try “TDD as if you mean it” which has very strict rules about where and when you should create your code, and when you can move it. It’s quite restricting the rules seemed to hold us back from getting very far. I was with Louis that time, who was very good at helping me to program in Java, which i’m not so familiar with.

At the 5th session we were allowed to just do whatever we want, so long as it was still test driven. I paired with Paweł and we just went a bit wild with linking cells to each other and getting them to link back respectively. We were going with North, South, East, West, but we eventually realised that you could really link any cell to any other, and the direction doesn’t matter. At that point it becomes more of a network problem. You could say that as a software coder i live or die depending on the community and people i know. That was an interesting insight.

In the final session I was with Clive and it turned out to be our best session of all. We were extremely controlled in our TDD, making sure we understood the code at each stage, and only taking small steps, and predicting at each test run whether it would pass or fail and what the failure message would be. We had cells that knew their positions, and could receive other cells and decide whether or not to attach to them as neighbours. Meaning we could pass every cell to every other cell and get them to connect based on their positions, then we could count how many neighbours they each have.

I mostly programmed in Ruby today, but there were people coding in Java, C++, C#, Python, and i think Scala, Clojure and PHP. We learnt a lot about how to program the game of life, and more importantly, how not to! A code retreat is a great opportunity to have fun, get to know other people, and code in an environment where it’s safe to try things out and make mistakes.

To find a code retreat near you, look on coderetreat.com or consider running your own!

Javascript BDD with Cucumber and Harmony

Inspired by tooky‘s recent post Exploring Harmony for javascript BDD with RSpec i have become determined to become better at writing javascript in a BDD kind of way.

On Monday we were privileged to have Corey Haines visit Eden for the day. I paired with Corey for a couple of hours learning about BlueRidge for unit-testing javascript classes in a Rails application. I liked what i learned but i am disappointed by the need to maintain HTML fixtures. I would like to run the specs directly on my application.

I was pairing with Tris today and we really wanted to run javascript straight from Cucumber scenarios, so we had another look at Harmony. The first thing we noticed that it needed to load a file (rather like a fixture), which we didn’t like very much. We went to see how HolyGrail does it.

Maybe it’s because we’re using Capybara not Webrat, or maybe it’s because we did something wrong, but we couldn’t get HolyGrail to work right. However, a quick peek at the source code gave us a few clues. We pulled out and tweaked the following:

def js(code)
  @__page ||= Harmony::Page.new(page.body.to_s)
  @__page.execute_js(code)
end

This worked pretty nicely for a step involving simple javascript, like:

Then /^the page is titled "([^\"]*)"$/ do |title|
  js('document.title').should == title
end

It was actually pretty exciting when we first saw that working! On to something more meaningful …

  Scenario: Use javascript to hide a box
    Given I am on a page with a box that can be hidden
    When I use javascript to click "Hide"
    Then the box should be hidden

Clicking the link with javascript actually wasn’t hard:

When /^I use javascript to click "([^\"]*)"$/ do |text|
  js("$('a:contains(#{text})')").click
end

We used jQuery to find the right link and click it using Harmony. Harmony sends the ‘click’ method straight through to the javascript object, which is pretty cool.

Ensuring the box disappears was a little more tricky. For the moment we’re just checking that the contents becomes empty.

Then 'the box should be hidden' do
  js("$('.hide_box')").html.should be_nil
end

Sure enough, when we plug in the unobtrusive jQuery code to bind the click and remove the box, the feature passes! Alright, this is a very small step down a long road, but to me it is very exciting indeed!

Next steps: we have already begun writing a Capybara driver to run Harmony. So that we don’t have to write a separate step definition When I use javascript to click “Hide” but we simply use the standard When I follow “Hide” and we tag the scenario with @harmony to use the alternative driver. That will first attempt to click it with javascript and, if nothing happens, it will follow the link in the normal way. We will also use the driver to handle when the @__page cached copy gets refreshed.

An important next step is make it a proper integration test, interacting with the full stack, such as clicking something which triggers an AJAX request to the server which must run a bit of code and send the response back to the page. I can foresee this presenting some challenges, we’ll see!

Exciting things are happening, and this is just the beginning! Web development these days is all about standing on the shoulders of giants. This is only possible thanks to the great work already being done by Harmony, Johnson and SpiderMonkey. I’m hoping that other people will become inspired by the possibilities and take this further. Watch this space for more news!

Presentation of my apprenticeship task

Here is a presentation i made to some of my colleagues on friday explaining my first apprenticeship task, my wiki, how i went about it, the problems i encountered and what i learnt from the whole experience.

See my Apprenticeship task presentation on youtube.