- 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
- 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 --wipwill 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.
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.
- 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.
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.
- 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)
Every now and again, our team creates a new Rails app.
The last time we did this, we had a discussion about how we could make our new Rails app easier to maintain and test, as well as reducing the duplication across multiple Rails apps.
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
- 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
- Instead of using constants in production.rb, use a configuration class.
- 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).
- Use Restfulie
I’m a great admirer of his many works, including Shoes (a great GUI framework), Hpricot (my HTML parser of choice), HacketyHack (a great way for kids to learn programming), TryRuby (a way to try Ruby in your Web Browser), and of course his Poignant Guide to Ruby.
Why’s Poignant Guide to Ruby was the first Ruby tutorial that I read. I liked its unique style and narrative that, for me at least, introduced Ruby concepts in a memorable way, particularly Dwemthy’s Array (see chapter 6) which introduced me to metaprogramming and DSLs in Ruby.
Please, let us all #clapwithwhy, and I hope he comes back to enrich the Ruby community with his creative genius.
I’ve recently switched back to using a Mac after many years using Ubuntu.
I much prefer OS X to Ubuntu, mainly because some of the software it has is not available on Linux, such as iTunes, and TomTomHome.
What surprised me is how many essential applications and functions were missing from OS X (10.5.7), when compared to a default install of Ubuntu (9.04).
Here’s the list of essential software to bring OS X to the same level as Ubuntu 9.04:
- Adium multi-protocol chat client
- Growl desktop notifications
- MenuCalendarClock a better menu bar calendar
- GoogleNotifier gmail notifier for the menu bar
- iStat menus System resource graphs for the menu bar
- Transmission BitTorrent client
- VLC a video player that plays anything (almost)
- RealPlayer because VLC can’t play some RealPlayer content
- OpenOffice because Microsoft Office is too expensive
Whilst installing all this software, I noticed what a pain it was, compared to the simple ‘apt’ or Synaptic in Ubuntu. If only there was a package management system for OS X that would allow me to install all the software I want.
On top of the essential software above, I installed the following, to get me to my minimum machine specification:
- Tweetie Twitter client
- FruitMenu allows you to customise your Apple menu
- Firefox because Safari just doesn’t cut it
- MacVIM for editing code
- Netbeans for Java ME development
- Mpowerplayer SDK because Sun don’t produce an OS X version of the Java ME tools themselves
- Rubymine for Ruby development
- Git source control
- gitx superior gitk/git-gui clone for OS X
- FFXporter Free Flickr eXporter iPhoto plugin
- ffmpegx for all your video conversion needs
- Fugu SFTP/SCP client
- Facebook Exporter for iPhoto
If I ever need to rebuild this Mac, it’s going to be a real pain downloading and installing all those applications again.
I’ve had an offline gem documentation server installed for a while on my machine, after following Jason Seifer’s instructions.
Recently, however, when I installed new gems I got the following error:
invalid argument: –fmt=html
This is, I think, because the hanna gem that provides the rdoc template needs to use a html output formatter, which seems to have disappeared from newer versions of rdoc.
As a solution, I’ve switched to the sdoc gem, which I think has a better rdoc template than hanna.
The full install instructions for my offline gem documentation server are:
- Install pre-requisites: Apache and Phusion Passenger – also add gems.github.com to your gem sources
- Install sdoc gem – this provides the rdoc template, that puts a search box on each rdoc page to allow you to search the methods and classes of a gem:
sudo gem install voloko-sdoc
- Edit your ~/.gemrc file, to add the correct options for sdoc, and (optionally) stop ri docs being generated:
gem: --no-ri rdoc: --inline-source --line-numbers --fmt=shtml --template=direct
- Regenerate all your rdocs so they all use the new sdoc template:
sudo gem rdoc --all --no-ri
- Install the sinatra-rubygems gem, to allow your gem rdocs to be served by passenger installed on your local machine:
sudo gem install jnewland-sinatra-rubygems
- Add the following to your /etc/hosts file:
- Add the following to your apache passenger config – customizing the DocumentRoot and Log locations as required:
<VirtualHost *:80> DocumentRoot "/opt/sinatra-rubygems/public" ServerName gems.local:80 ErrorLog /var/log/apache2/gems-error_log CustomLog /var/log/apache2/gems-access_log common </VirtualHost>
- After restarting apache, you should then be able to visit gems.local