The main ‘features’ are: OSX support and the source moved to Github. Read more

Developers usually hate spec documents. Not the documents themselves, or  writing specs, but we hate the future agony a written document represents. Documents need to be updated many times, by different people, and most of them ends up as static, historical dinosaurs documenting not the features of our system, but our premature understanding of our system that happened to turn out quite differently.

The nice cucumber framework comes to the rescue, changing rigid document specs into runnable code without losing business readability, and even adding a needed tightening of a usual sloppy spec syntax.

The problem is….

Many people prefer nice-looking, printable documents.

So after trying to convince business people to accept the cucumber features, each in its easy-to-read raw text file, they still seem to need those documents.

So following up on an old cucumber feature request, I wrote a PDF formatter using the ‘prawn’ library.

In my opinion such a PDF is for presentation purposes only (which is why I think we should never need a doc/odt/rtf/pages version), as any editable form would undermine the whole idea of executable specs.

The formatter entered cucumber mainline yesterday, and is part cucumber since 0.3.101 (15/9 2009).

You need a recent  prawn gem installed for this to work:

gem install prawn

Example of usage:

cucumber --format pdf --dry-run --out my-file.pdf   features

This will generate a nice PDF of the features and scenarios, avoiding page breaks in scenarios.

You can place your own logo in features/support/logo.png and the formatter will pick it up and display it on the front page, along with the generation time and the command line used.

You can even run the actual features using this formatter, and the PDF will be colorcoded according to run status.

Heres a screenshot:

As soon as the cucumber is released, we will  a page on the cucumber wiki with some more examples and docs.

Enjoy.

I’ve recently started using cucumber. The BDD is starting to dawn on me, even though I still have some reservations.

Since my current project uses the continous integration server ‘hudson’, I really wanted the old-fashioned junitreport output from cucumber, so hudson would report any regression errors as soon as possible.

I looked at some on the existing attempts at a junit formatter, but none where quite good enough, IMO. I needed duration times, and the mapping:

• 1 feature -> 1 testsuite
• 1 scenario -> 1 test

So I forked cucumber, and wrote one from scratch. This code made it into cucumber in August, and can now be used as

cucumber –format  junit –out DIR

I’ve written more info on the cucumber wiki:  http://wiki.github.com/aslakhellesoy/cucumber/continuous-integration

Enjoy, everyone.

Replace the -iwholename with -ipath in the ‘find’ command.

Thanks for sharing.

Mads

cowboy-coding

Today I spoke at the University of Copenhagen, Institute of Computer Science about the use of agile methods in ‘the Enterprise’. I doubt it will be of much use to non-danish speakers, except for some funny pictures. Anyway, I’ve uploaded it here:

agile_enterprise2 (PDF, 11MB)

I especially like the random flickr image I found and edited showing my idea of a ‘Cowboy-Coder’:

(I’m a bit of a cowboy-coder myself in my spare time :-))

(Thanks to the great project MacPorts it is now possible to install gtk and gnome applications on your mac almost as easy as in Linux. The GUI tool Porticus makes it ‘point and click’).

With a brand new MacBook pro 17″ in my hands, I could not resist installing gedit and snap open to see how that would work:

Here it is:

There were some issues… and there are still some.

First of all: Get rid of that horrid default gtk theme that scares so many away from gtk apps. Install gtk-theme-switch from MacPorts and download a proper skin from www.gnome-looks.org. (This one is called ‘Leopardish’).

Installing the plugin was a bit tricky and I ended up putting my snapopen plugin files directly into

/opt/local/lib/gedit-2/plugins/

Furthermore, the ‘find’ command we all love, and my plugin relies heavily on, on Mac does not support the -iwholename flags, but instead the -ipath so that was easy.

Next issue was the keyboard shortcuts CTRL+ALT+o does not work out of the box. I switched to SHIFT+CTRL+o which works fine (I will fix this properly later).

Now it works… well almost:

The filebrowser integration seems to be quirky, and it often falls back to ‘wd’ (working dir).

I might do a ‘Mac’ version soon, so it will work here as well, although it would in the form of a ‘Mac-detect flag’ not a code fork.

Until next time…

Link to original (linux only) snapopen plugin

• xsl templates (<xsl:value-of select=”$hello_world”/>) thats didn’t suck?!,
• to hudson, a happy reunion, “every Batman should have a butler :-)”
• to ubuntu jaunty on my laptop - very nice
• and to Rails footnotes plugin. Where have you been?
• And lastly of course..

HELLO Wordpress. Installed it and started typing. The coming days will hopefully change this ‘defaulty’ sites appearance and content.

For those of you just looking for my ‘Snap Open’ plugin for Gedit (Linux text editor), you can find it here