Debian breaks on Virtuozzo VPS
December 14, 2007
Apologies if you are looking for any articles or trying to post a comment and you are getting 404 errors, or if you wondered where jbehave.org or behaviour-driven.org had gone. Over the last few days I’ve managed to completely hose my server running Debian “testing” distribution, and I’ve had to downgrade to Debian “stable”. This involved some rsync backups and a complete reinstall of the virtual server.
Apologies especially to the lovely people whose blogs I host and who have been extremely patient with me over the last few days.
Because stable is about a year out of date, it is several versions behind fast-moving projects like WordPress, so I have some more fiddling to do before permalinks or comments will be working again.
If you are running Debian/testing in a Virtuozzo VPS, check your kernel version. It seems Virtuozzo uses a broken RedHat 2.6.9 kernel which simply doesn’t work with current Debian/testing packages. If your VPS provider uses a broken kernel, DO NOT UPGRADE libc6 to the current version (2.7) otherwise your system will simply die on its feet. It’s incredible – /bin/ls stops working, so does ssh (so you can’t log in to fix it!) – in fact it seems a huge weakness in the Debian setup. I would have expected the core admin packages and system binaries to be statically linked to avoid exactly this problem. A statically-linked busybox helped me enormously here while I monkey-patched it enough to get it to boot.
For the record, here’s my experience so far:
Places to back up
- /etc (all the system settings)
- /home (also contains /home/vmail where all the virtual mailboxes live
- /var/lib/mysql (lots of WordPress databases)
- /usr/share/wordpress/wp-content (mostly for themes and plugins)
- /var/www (wikis)
I’m quite pleased things were this well organised. I thought I might be looking for files all over the place.
Things that worked
- openssh with my existing config and keys. Hurrah!
- postfix and dovecot. Although that’s hardly surprising – they are both rock solid and quite stable. I just rsync’ed the mail directories and settings back and they both started working. After a recommendation by Steve Purcell I’ve been using dovecot as my imap server and authentication daemon with postfix and they are a joy.
- apache2. Enough said.
- mysql 5. I’m really starting to like mysql.
- moinmoin. Needed some love. Actually I needed to clear out all the caches before it would work, and install packages moinmoin-common and python-moinmoin, and of course libapache2-mod-python.
Things that don’t work
- Apache2 mod-fcgi. I was having problems with this before which went away when I upgraded to Debian/testing, so I’m assuming it just doesn’t work properly in Debian/stable.
- Apache2 mod-svn. It just doesn’t exist in stable, and neither does mod_dav, so I can’t do funky internet filesystem things for my Windows friends.
Things I’m still struggling with
- Links in WordPress. This is bound to be something really obvious that I’ll work out after a good night’s sleep. It seems ok for some blogs and not for others, so it might be to do with the themes. Update: it turns out I needed a @/usr/share/wordpress/.htaccess@ owned by the apache user with the appropriate rewrite rules in it – thanks Ben Coleman for sorting that out.
So far my VPS hosting company, Solar VPS, have been great with any support requests I’ve made. I really hope they come through with an up-to-date kernel so I can dist-upgrade everything back to Debian/testing. _Update: Virtuozzo has no plans to upgrade the kernel before its next major release, so I’m stuck with Debian Stable (Etch)._
Empty rooms
October 9, 2007
It’s now about two weeks to OOPSLA, where Liz Keogh and I will be presenting a workshop on behaviour-driven development using JBehave. This will be along similar lines to the workshop I co-presented at RailsConf Europe last month.
At RailsConf we presented to nearly 200 people, which was about a quarter of the conference attendees. At JAOO last year Niclas Nilsson and I presented BDD to well over 100 people. So far at OOPSLA only a handful of people have signed up for the workshop. I’m curious. Is it that the people attending OOPSLA aren’t interested in behaviour-driven development? Is it JBehave? Is it that we haven’t marketed it very well? Is it simply the cost?
RSpec, the ruby equivalent of JBehave, is comparatively much more popular. It has been embraced by the Rails crowd and by rubyists in general in a way that JBehave doesn’t seem to have been in java. Perhaps JUnit and JMock were already so pervasive in the agile java community that there wasn’t room for JBehave, or perhaps it wasn’t seen as different enough to be worth trying – its early incarnations were as just another TDD and mocking tool.
Since I started writing JBehave back in 2003, BDD – and JBehave itself – has broadened in scope, covering user stories right the way through to tested, deployed code, and the OOPSLA workshop will explore this bigger picture. It will be of interest to anyone looking to understand behaviour-driven development, regardless of the technology stack or toolset you use.
On a related theme, java is trailing behind ruby and even C# in terms of customer-friendly executable documentation. JBehave might just be the tool to follow through on the promise of FIT, to define executable acceptance criteria that can be authored by testers or analysts.
So to anyone going to OOPSLA, if you aren’t coming to the BDD session I would be very keen to hear why so I can pitch it better next time. Is it that you aren’t using JBehave so you don’t think the session is relevant? Are you simply not interested in BDD? Is there too much other good stuff on at the same time? Or did you just not notice but now you have you’ll be signing up? I hope to see you in Canada!
Upcoming events
September 10, 2007
So it’s that time of year again. I’ve got a number of conferences and workshops coming up, ranging over all sorts of topics. I just popped over to Martin Fowler’s site (I’m doing a talk with him this week) and noticed that he has a much more organised setup than me. All his events are in a sidebar and there is a handy link if you want more details. Another idea to go on my to-do pile.
ThoughtWorks Quarterly Technology Briefing
- Manchester – 12 September 2007
- London – 20 September 2007
This is the second instalment in ThoughtWorks series of informal sessions aimed at technologists across the spectrum. Although calling it a technology briefing is a bit inaccurate because the title for this one is “How to Sell Agile to your Organisation”, which has far more to do with the themes of people, risk and change than with anything technological.
This is the talk I’ll be presenting with Martin so I can guarantee a lively session. In his own words: “As I detest selling anything to anyone it will be interesting to see how this talk works out.”
Details and registration info are on the ThoughtWorks website.
RailsConf Europe
- Berlin – 17-19 September 2007
A lot of Ruby folk seem to have taken to behaviour-driven development. This is almost entirely due to the success of the rspec project, which is in turn due to the enthusiasm and dedication of its developers and the community they have established.
A while back I wrote a story-level BDD framework for Ruby called rbehave which has since been integrated into the rspec project.
I’ll be helping rspec project leads David Chelimsky and Aslak Hellesoy present a workshop entitled A half-day of behaviour-driven development on Rails, where we’ll be demonstrating how rspec helps you write software that is focused on achieving an outcome. It’s at 8:30am on the Monday morning, so make sure you’re there first thing.
Expo-C Roadshow
- Växjö – 15-16 October 2007
- Karlskrona – 17-18 October 2007
Expo-C is one of my favourite events. It’s a small conference in south-east Sweden and it seems to attract an audience that really cares about what they are doing. I’ve done two of them now, on very different topics, and on both occasions I was very impressed with the quality of the attendees and the calibre of the other speakers. (I’m usually the only one there who hasn’t written a book.)
This time they are doing two mini-conferences back to back, in Växjö and then Karlskrona, with a tutorial day and a seminar day (six sessions) in each location. I’ll be running full-day tutorials on BDD in Växjö, and Coaching, Communication and Change in Karlskrona. For the seminar I’ll be talking about bridging the communication gap, based on a keynote I gave with Martin Fowler at QCon earlier this year.
I will also be learning how to pronounce “Växjö”.
OOPSLA
- Montreal – 21-25 October 2007
This will be my first OOPSLA. I’ve heard a lot about it and I’m a bit intimidated. By reputation it seems a bit more “cerebral” than most conferences. It will also be the first time I’ve ever presented JBehave at a conference. No mean feat considering I started writing it at the end of 2003! There’s perpetual beta for you.
My co-presenter is my ThoughtWorks colleague, friend and cybergoth Liz Keogh, the person responsible for getting JBehave to 1.0. I have huge respect for Liz; she manages to combine software with poetry. This isn’t a pretentious metaphor – she actually does combine software with poetry. She ran a haiku workshop at a previous ThoughtWorks away day that many of the attendees nominated as the highlight of their day. She also writes inspiring and inspired blog articles.
I’m only going because I want to see what Liz does when she’s let loose on a roomful of developers. I reckon we’ll end up writing haiku acceptance criteria.
And some others…
There are another couple of events in the pipeline that I will blog about nearer the time (January and February next year). After that I’m going to have a bit of a lie down.
Correction: I got the dates wrong for OOPSLA. Thanks Joshua Graham for putting me straight.
_Another correction: My Swedish geography is appalling. Thanks Morgan Persson._
Virtual mailboxes with courier-imap and postfix
September 9, 2007
This is the first of an occasional series of posts about Linux systems administration. I’ve been an on-off Linux sysadmin for about, well, my first Linux was Slackware on a stack of 3.5″ floppies. Every now and then I do something “fiddly” and I want to capture these episodes in case I ever need to do it again, or in case someone else wants to and they find this useful.
I run Debian Testing on kenny, the server that hosts http://dannorth.net, http://behaviour-driven.org and a bunch of other websites, blogs and wikis. (Random plug: it’s hosted by the fine folks at SolarVPS. I have no affiliation with them but they rock.) It seems a good balance between Debian Stable – which is rock solid but always about a year out of date – and Unstable, which requires updating far too often and hosed my old server (cartman – can you see a theme here?).
Mostly it Just Works. In particular WordPress and MoinMoin are a joy to configure and use. I get change out of about 10 minutes to add a new blog.
I also use it as a mail server, using postfix for sending and receiving mail and courier-imap for reading it. I tried a number of mail servers and settled on postfix after dismissing sendmail and qmail as just too complicated and exim after staring at the impenetrable documentation one time too many.
I found it pretty easy to set up secure SMTP over TLS and secure IMAP over SSL, but I stumbled at setting up virtual mail addresses. This article is about how to do that using postfix and courier-imap. It’s pretty straightforward once you know where all the moving parts are, but they were less than obvious to me.
Virtual mail addresses
Mostly you send email to bobaddress.com and it turns up in bob's mailbox in bob's login account. Sometimes you don't want this. For instance, I host about 20 domain names on kenny, and addresses like infoblah.com or salesblah.com need to go to specific people. That's the first type of virtual addressing, known as virtual alias domains.
The second case is "more" virtual - the user doesn't even need to exist on the server with a regular login account. Postfix puts the mail into a special directory, and courier-imap presents that directory as the mailbox when the user "logs in" over IMAP. This is where all the moving parts come in. This is known as virtual mailbox domains.
Setting up postfix for virtual alias domains
This is the easier of the two, since the mail ends up in a real email address, so there is no corresponding configuration on the courier-imap side. This information came from the Postfix Virtual Domain Hosting Howto.
In /etc/postfix/main.cf@ add the following lines:
virtual_alias_domains = dannorth.net
virtual_alias_maps = hash:/etc/postfix/virtual
This says that postfix will treat the name dannorth.net as a virtual alias domain and will use the file @/etc/postfix/virtual@ to do the mappings. Your @/etc/postfix/virtual@ might look like this:
# deliver to local account
dan<code>dannorth.net dan
# forward to another mail address
example
dannorth.net danexample.com
Once you have this file configured, run the command:
postmap /etc/postfix/virtual
to create the hash database that postfix will use, then run:
postfix reload
to update the configuration.
Setting up virtual mailbox domains
Ok, there are several moving parts here. We need:
- a directory to deliver the mail to
- to tell postfix to deliver it there
- to enable virtual users in courier
- to tell courier where the virtual users’ mail lives
In this example, I’ll set up two virtual users, fred and barney, at example.com.
System accounts and directories
The virtual users’ files need to be owned by someone, so we’ll create a “fake” user and group. I’m using vmail@ for both the user and group names, with uid and gid both set to 5000.
From a root prompt:
# groupadd -g 5000 vmail
# useradd -g vmail -u 5000 vmail
# mkdir -p /home/vhosts/example.com
# chown vmail:vmail /home/vhosts/example.com
Configuring postfix for virtual mailbox domains
In @/etc/postfix/main.cf@
virtual_mailbox_domains = example.com
virtual_mailbox_base = /home/vhosts
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 100
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
This is pretty self-explanatory. It says example.com is a magic virtual mailbox domain, all users and groups map to a fixed number (you can get cleverer than this but I'm not worried about it for now), and that all the interesting stuff is in @/etc/postfix/vmailbox@. The minimum uid is postfix's safety measure in case I do something stupid. It means I can't accidentally let someone have access to system files.
Now let's look at @/etc/postfix/vmailbox@:
fred<code>example.com example.com/fred/
barney
example.com example.com/barney/
The magic here is the @/@ at the end of each line. This says to use maildir format (the format courier-imap is expecting) rather than clunky old mbox format. Postfix will create the appropriate directory structure for fred and barney,
Again we create a hash of this for postfix:
# postmap /etc/postfix/vmailbox
# postfix reload
Phew! That's the postfix side done. Now stop for a cup of tea.
Configuring courier-imap for virtual mailboxes
On Debian, courier imap runs as three executables, each with separate init.d scripts. courier-imap and courier-imap-ssl are the imap servers themselves (I run courier-imap bound to localhost for webmail). courier-authdaemon is the chap that does all the authentication. That's the one we're interested in.
Firstly, we need to enable virtual users. In the file @/etc/courier/authdaemonrc@ you need to make sure your authmodulelist setting contains authuserdb as one of its authentication mechanisms. Mine looks like this:
authmodulelist="authuserdb authpam"
Don't forget to tell the auth daemon you've made a change:
invoke-rc.d courier-authdaemon reload
Courier uses a file called @/etc/courier/userdb@ to store virtual user mappings, but you don't usually edit this file yourself. It has an arcane format (using tabs and pipes as delimiters) and should be left well alone. Instead, courier provides you with some command line tools to manipulate it.
To create an entry for fred, we do this:
# userdb fred set uid=vmail gid=vmail home=/home/vhosts/example.com/fred mail=/home/vhosts/example.com/fred
(That should all be on one line - your browser might wrap it.) Then set a password for fred:
# userdbpw -md5 | userdb fred set systempw
Do the same for barney. Finally we build the hashed user database that courier will actually use:
# makeuserdb
Note: don't forget to run makeuserdb after making any changes to the virtual user data otherwise courier won't know.
Testing the configuration
Firstly, try sending an email to the virtual user. Postfix should create the maildir structure under example.com/fred. Then try connecting to courier to read the mail. If you find you are getting authentication problems from the courier side, you can try setting DEBUG_LOGIN=1 in @/etc/courier/authdaemonrc@ and restarting the auth daemon. Don't forget to switch it off again once it's working.
SOA for the rest of us
September 2, 2007
Earlier this year I wrote an article to introduce service-oriented architecture to non-technical people. It was published in the May 2007 issue of Better Software magazine.
The kind folks at Better Software have allowed me to provide a PDF version of the article, complete with retro 1950s graphics. You can also read it as a single html page.
Please post any comments here, because I’ve disabled comments on the page itself.
Two flavours of BDD – or .net gets behaviour-driven
June 27, 2007
How about that? You wait ages for a BDD framework in .net and then two come along at once! Ok, to be fair NSpec has been around for a while. However I’m talking about describing application behaviour in terms of stories and scenarios, to complement NSpec’s description of interactions between objects. (As a side note, I would love to see NSpec adopt rspec’s describe/it vocabulary rather than using contexts and specifications.)
Introducing NBehave and, well, NBehave!
Morgan Persson first spoke to me about writing a .net version of JBehave at the beginning of 20071, so I am delighted that he has just announced his first public release of NBehave. It mixes C# and VB.net in a lovely it’s-all-about-the-CLR way. So the examples are in C#, extending VB.net framework classes.
In the meantime, Joe Ocampo has used some C#3 voodoo to create something scarily similar to rbehave for .net. He seemed to produce this in slightly less time than it took me to press “publish” in WordPress, and I have to say it looks great.
Two use cases for expressing intent
The original idea behind the JBehave story framework was that developers would write “pluggable” givens, events and outcomes to define the various scenarios that make up each story. Non-technical people would then manipulate these using desktop tools (say a graphical story builder where you drag the various components around to define your stories and scenarios).
rbehave has a different motivation, namely moving from the textual representation of a story to an executable definition in as few steps as possible. This is to allow human beings – mainly testers and business analysts – to read, write and edit executable acceptance criteria.
Liz Keogh and I are currently preparing a JBehave tutorial for OOPSLA 2007. Since JBehave was based very much on the first use case, we’ve noticed it is pretty painful to pull together a story from a standing start, without a proliferation of tiny classes emerging. I’m working on a fluent interface that is currently looking a little like this:
public Story story() {
return newStory("I can create a cell")
.asA("game producer")
.iWant("to create a cell")
.soThat("I can show the grid to people")
.withScenarios(
scenario("Nothing to see here",
given("a game with dimensions", 3, 3),
then("the grid should look like",
"...",
"...",
"...")
)
);
}
It’s backed by the regular JBehave classes and runs in the standard JBehave story runner.
I would love to see Morgan and Joe bring their two interpretations of acceptance-level BDD together into a single framework. It is after all just a bunch of scenario fragments playing nice together, and having the two approaches to expressing intent in the same framework means that NBehave could be both a directly-editable representation of behaviour, and at the same time the basis of a (graphical?) toolset for defining acceptance criteria in .net. Maybe even as a Visual Studio plugin.
1. Oops – I thought it was as long ago as 2006 but Morgan put me straight.
Catching up
June 19, 2007
It turns out that having a day job can play havoc with your blogging activities. I’m posting a round-up of recent activities, in no particular order, with the intention of expanding on each of these topics in the coming weeks. But we all know what happens to intentions.
This is mostly a brain dump to make me feel guilty enough to write some of it up, so feel free to skip it if you’re busy. That FaceBook page isn’t going to update itself you know.
Simplicity
At last year’s XP Day in London I got involved in a fishbowl discussion, with the likes of Kevlin Henney among others. Kevlin gets simplicity. To me it’s the holy grail of software development, and it’s all about expressing intent clearly. If you can’t make a system any simpler, then you’re done (simple, not simplistic). Likewise if you can express the intent of an application in a clearer way, you still have work to do. Erik Doernenberg and I shaped this theme into a keynote that I’ll pretend I’m going to write up at some point.
Performance tuning
A couple of years ago I did a performance tuning gig with a major retailer in the US. It was their first foray into J2EE and they were struggling with the impedence mismatch between OO and the relational database. Over the next few weeks I’ll be writing up the various approaches we took to achieve the results we got (startup time down from 10 minutes to 45 seconds, query times down from over 30 minutes to sub-second), because in the intervening period I’ve seen some of the patterns repeating themselves elsewhere.
Agile SOA
I have my “safe” topics that I’m very familiar with presenting: coaching and learning, agile and BDD, various technology topics. Last month I presented outside of my safe zone – on “SOA for Human Beings” at the ExpertZone conference in Stockholm.
SOA is not like the other kids. On one level it’s so vague it’s almost Zen: “What is SOA?” “It’s whatever you want it to be”. Secondly, it’s largely misunderstood as being a technology thing rather than a business thing. Thirdly, it’s often deliberately misrepresented as the reason you have to purchase a particular toolset.
So I stood up in front of the 17 attendees and said: we won’t be discussing code this afternoon – we might not even discuss technology. And we all had a much better afternoon because of it. There were a number of themes that came up during that session, and I’ll try to do them justice in a future article.
Builders, Commands and Fluent Interfaces
I’ve been architecting! You know, like properly designing software on a project as a tech lead. It’s great fun – I’d forgotten how much I liked it. My favourite current toys are builders – in particular fluent interfaces – and the command pattern. Suddenly my world is a simpler and happier place. Come to think of it, I’ve just rolled off a project with Patrick Kua as my tech lead. Talks a lot of sense does Patrick.
BDD in Ruby
Got rbehave out. Phew!
BDD in Java
At some point in the last couple of months, it seems we released JBehave 1.0! It’s been a labour of love, made up of infrequent short bursts of activity interspersed with long periods of day job. Lucky for me, Liz Keogh stepped up and took the reins, and with the help of some other great developers got it to 1.0. I’m very pleased with what we’ve accomplished so far, but there’s plenty more to do. In particular I want to introduce a fluent story builder to remove the need to hand-wire all the stories, and see if we can use some Java 5 goodness to simplicate things.
Real Options
No, not the things traders buy and sell. This is an overlooked branch of mathematics that explains why deferring decisions responsibly is a Good Thing, but deferring them past their “use by” date is just dumb.
My good friend Chris Matts has written an article about real options with Olav Maassen. In a demonstration of the interconnectedness of all things, there are at least two JBehave connections here. Chris was the guy who made the observation that BDD-as-TDD was just like business analysis, which in turn led to the whole story/scenario vocabulary. Olav was the first contributor to JBehave, writing a JBehave Ant task back in 2004. They are both mad as a box of badgers which means the article makes for interesting reading.
Introducing rbehave
June 17, 2007
rbehave is a framework for defining and executing application requirements. Using the vocabulary of behaviour-driven development, you define a feature in terms of a Story with Scenarios that describe how the feature behaves. Using a minimum of syntax (a few “quotes” mostly), this becomes an executable and self-describing requirements document.
BDD has been around in the Ruby world for a while now, in the form of the excellent rspec framework, which describes the behaviour of objects at the code level. The rspec team has focused on creating a simple, elegant syntax and playing nicely with other frameworks, in particular Rails and the Mocha mocking library.
Inspired by this, I wanted to find a simple and elegant way in Ruby to describe behaviour at the application level. This is a different enough problem that I couldn’t just use rspec. You can skip ahead to the Ruby code if you already know about stories and scenarios. This preamble just sets the scene for the example.
The scenarios that describe a story are made up of “steps” of Givens, Events and Outcomes. These steps can be mixed and matched in different ways to provide different sequences of events. Here is an example:
Story: transfer to cash account
As a savings account holder
I want to transfer money from my savings account
So that I can get cash easily from an ATM
Scenario: savings account is in credit
Given my savings account balance is \$100
And my cash account balance is \$10
When I transfer \$20
Then my savings account balance should be \$80
And my cash account balance should be \$30
Scenario: savings account is overdrawn
Given my savings account balance is -\$20
And my cash account balance is \$10
When I transfer \$20
Then my savings account balance should be -\$20
And my cash account balance should be \$10
Here we have two givens: one about my savings account and the other about my cash account. We have a single event, namely transferring cash. We have two outcomes, again about the account balances.
This is typical of the scenarios in a story: they revolve around a single event (the feature itself) and prescribe different outcomes for different combinations of givens. Also, notice that the steps themselves are parameterized: the first time my savings account balance is $100, the second time it is -$20, so a story framework needs to accommodate this.
Getting it running
So then I converted the story into a rspec-like structure, preferring simple strings to method names, and do/end blocks rather than classes:
require 'rubygems'
require 'rbehave'
Story "transfer to cash account",
%(As a savings account holder
I want to transfer money from my savings account
So that I can get cash easily from an ATM) do
Scenario "savings account is in credit" do
Given "my savings account balance is", 100
Given "my cash account balance is", 10
When "I transfer", 20
Then "my savings account balance should be", 80
Then "my cash account balance should be", 30
end
Scenario "savings account is overdrawn" do
Given "my savings account balance is", -20
Given "my cash account balance is", 10
When "I transfer", 20
Then "my savings account balance should be", -20
Then "my cash account balance should be", 10
end
end
Using rspec to drive the design, I wrote a little framework that would run these scenarios, each one in its own instance of an object (so they were independent), reusing the steps as needed.
So, this only left the problem of the steps themselves. They would have to be defined somewhere else (that I hadn’t figured out yet). Then I thought: each step’s implementation should be pretty trivial, so what would happen if I put the code for each step inline in the scenario? So I ended up with this:
require 'rubygems'
require 'rbehave'
require 'spec' # for "should" method
require 'account' # the actual application code
Story "transfer to cash account",
%(As a savings account holder
I want to transfer money from my savings account
So that I can get cash easily from an ATM) do
Scenario "savings account is in credit" do
Given "my savings account balance is", 100 do |balance|
<code>savings_account = Account.new(balance)
end
Given "my cash account balance is", 10 do |balance|
cash_account = Account.new(balance)
end
When “I transfer”, 20 do |amount|
savings_account.transfer_to(cash_account, amount)
end
Then “my savings account balance should be”, 80 do |expected_amount|
savings_account.balance.should == expected_amountcash_account.balance.should == expected_amount
end
Then "my cash account balance should be", 30 do |expected_amount|
end
end
Scenario “savings account is overdrawn” do
Given “my savings account balance is”, -20
Given “my cash account balance is”, 10
When “I transfer”, 20
Then “my savings account balance should be”, -20
Then “my cash account balance should be”, 10
end
end
For this example it turns out there are no new steps to define in the second scenario, which makes it very easy to read. In general I'm finding that most of the steps get defined in the first one or two scenarios.
Implementing the code
So I saved this to a file as transfer_funds.rb and ran it, and I got two failures:
Running 2 scenarios: FF 2 scenarios: 0 succeeded, 2 failed FAILURES: 1) transfer to cash account (savings account is in credit) FAILED NameError: uninitialized constant Account ... 2) transfer to cash account (savings account is overdrawn) FAILED NameError: uninitialized constant Account ...
rbehave prints one character per scenario - a dot means the scenario passed, an F means it failed. At the end of the run it prints a list of the failing scenarios. So this tells me that firstly it runs (hooray!) and secondly both scenarios are failing because I'm missing an Account class. Well I don't want a whole bunch of failing scenarios that only start to work one at a time as I implement them. That feels too much like broken windows - I'll get too used to seeing failing scenarios and then I won't react when workng scenarios start failing. So I introduced the idea of a "pending" scenario, by adding a pending() method:
Given "my savings account balance is", 100 do |balance| pending "needs an Account" <code>savings_account = Account.new(bal) end
And I got this:
Running 2 scenarios: PP 2 scenarios: 0 succeeded, 0 failed, 2 pending Pending: 1) transfer to cash account (savings account is in credit): needs an Account 2) transfer to cash account (savings account is overdrawn): needs an Account
The Ps represent pending scenarios, which means they aren't working yet but they don't count as a failure. Then I use rspec to implement an Account with a constructor that takes an initial balance, and give it a transfer_to@ method that moves money around. Then I remove the pending line:
Running 2 scenarios: .F 2 scenarios: 1 succeeded, 1 failed, 0 pending FAILURES: 1) transfer to cash account (savings account is overdrawn) FAILED Spec::Expectations::ExpectationNotMetError: expected -20, got -40 (using ==) ...
Excellent! I have my first working scenario. Now I just need to add behaviour to the Account class to not transfer money it doesn't have! But wait a minute, what about documentation? Well I added some listeners to the story runner, so when you run:
transfer_funds.rb --dry-run --format simple
you get:
Story: transfer to cash account As a savings account holder I want to transfer money from my savings account So that I can get cash easily from an ATM Scenario: savings account is in credit Given my savings account balance is 100 Given my cash account balance is 10 When I transfer 20 Then my savings account balance should be 80 Then my cash account balance should be 30 Scenario: savings account is overdrawn Given my savings account balance is -20 Given my cash account balance is 10 When I transfer 20 Then my savings account balance should be -20 Then my cash account balance should be 10
This is being generated from the same Ruby code that runs the scenarios themselves.
Next steps
You can gem install rbehave or download the source. There is a sample application (Conway's Game of Life) in progress in the source code that shows you some of the other features rbehave supports.
rbehave was designed to play nice with other frameworks. In particular, the "world" that each scenario runs in is a module that can be mixed into any object, so you could easily use rbehave with a Rails IntegrationTest or incorporate it into your existing acceptance testing framework. It is also possible, and in fact encouraged, to use rspec in your Outcomes (balance.should == 30).
If you're interested in using or developing rbehave, please join the mailing lists and let me know how you get on. As a parting thought, rbehave is totally compatible with jruby, so you could start writing your Java acceptance criteria in Ruby and running them in rbehave.
A number of people helped me get rbehave off the ground. In particular I have to thank Niclas Nilsson for kick-starting the whole thing, David Chelimsky (rspec lead) for his sound advice and for adding describe/it to the rspec core, Liz Keogh (jbehave lead) for demanding that steps should take parameters and not taking no for an answer. Also PragDave ran an inspiring meta-programming workshop at QCon that gave me the courage to try this stuff.
Upcoming Talks
February 28, 2007
I’ve got a number of tutorials, conference sessions and keynotes coming up over the next few months that I’m very excited about. My themes for this year are behaviour-driven development, SOA for human beings and understanding what simplicity really means. Looking at these, there is an overarching theme about getting different kinds of people talking to each other in plain English (for some value of English).
Keynote at QCon, 14-16 March, London
QCon is the London version of the excellent JAOO conference in Denmark, which has become my favourite technology event of the year (apart from phone upgrade time). They attract world-class presenters to provide sessions varying from the deep technical through to people and process topics, and they’ve done the same with QCon. What’s more, they have managed to resist the lure of the sales-pitch session, which means you get to hang out with other geeks without people trying to sell you stuff. The London event is being run in conjunction with the common-sense guys at InfoQ, and I’m lucky enough to be speaking there.
I’m delivering a keynote with Martin Fowler about the gaping crevasse between what business people ask for and what technical people think they want. I’ve presented with Martin a couple of times before – at least I know I’ll only be the second loudest person in the room.
ThoughtWorks is a “platinum sponsor”, which I think means we get to buy more drinks than the other sponsors.
BDD in Ruby at ACCU, 11-14 April, Oxford
ACCU is a conference by geeks, for geeks. With its roots in the C++ community, there are lots of strange people in weird industries like embedded systems, graphics engines and writing music software. It’s a refreshing change for me, where “enterprise systems” usually means moving data from over here to over there.
I’m actually at ACCU by accident, presenting behaviour-driven development in Ruby. They haven’t noticed yet that I haven’t touched C++ in ten years, and I’m not about to tell them.
However, the ACCU folks are developing a strong liking for dynamic languages – last year Guido van Rossum, the inventor of Python, delivered a keynote, and I co-presented a session introducing Ruby and Rails. So perhaps there’s life after the standard template library after all 
Coaching workshop and BDD session at Expo-C, 23-25 April, Gothenberg
You know the tutorial days that tend to happen either side of a conference? Well Expo-C has adopted the model of having mostly tutorial days and hardly any conference! The 23rd and 25th are tutorial days, with two speakers presenting full-day tutorials on each day (I’m on the 23rd). The middle day is made up of seminars by a number of presenters. As the only speaker who hasn’t published a book (one of the presenters, Jim Coplien, has a small library to his name), I can safely say it’s a very solid line-up. Also, it’s one of the smaller conferences so there is lots of opportunity to hang out with the presenters.
I presented a tutorial day last year around the theme of agile delivery and thoroughly enjoyed it. This year I’m doing something a bit different, focusing on “Change, Coaching and Communication”, using NLP and life coaching principles as the basis of a one day interactive workshop. As with last year, there won’t be any PowerPoint, mostly because I’m rubbish with PowerPoint.
I’ll also be presenting a behaviour-driven development session on the seminar day.
Keynote and SOA workshop at ROOTS, 25-27 April, Bergen (Norway)
I’ve not been to ROOTS before but I’ve heard good things about it. It’s a developer-centric conference and this year it features the likes of Kevlin Henney, Jim Coplien (who I’ll be racing to Norway from Expo-C) and lovely testing guru Linda Rising.
Erik Doernenberg and I are delivering a keynote on the nature of simplicity, and we’re running a three hour workshop looking at SOA for human beings.
Keynote and SOA workshop at ExpertZone, 23-25 May, Stockholm
I met Josefin Andersson, one of the organisers of ExpertZone, earlier this year and she convinced me I had to attend the ExpertZone Developer Summit in Stockholm. Since I’m scared of Josefin, I said yes. Also Microsoft’s Beat Schwegler will be there, and he rocks.
I’ll be delivering another keynote with Erik Doernenberg, based on our current pet themes of simplicity and clarity of intent (honestly, how hard can software be?), and running the workshop on SOA for humans.
I’ve been told by the Boss that I’m not allowed out of the house in June.
Monkey business value
February 15, 2007
So I was hanging out with a bunch of geeks in Switzerland, having one of those late night conversations, and an idea sort of emerged, and the more I thought about it, the more I liked the idea. And then I was thinking that a) I’m useless at following through on ideas and b) I would love someone to take this forwards. So here it is.
Our premise was that the value of automated testing is in its repeatability and low investment (in terms of human effort). However, running the same tests all the time just verifies that the system does a small number of well-known activities.
The value of exploratory testing, on the other hand, is to try all the weird combinations that people might try – aka monkey testing – in order to break the system by using it in unlikely ways. The problem is that exploratory testing requires people, so it’s slow and expensive.
Cue RMonkey (and possibly PyMonkey and JMonkey). RMonkey augments your Ruby acceptance tests, to emulate monkey behaviour. It works like this:
Boring, old-style test:
def test_user_can_login
web.navigate_to '/login'
web.enter_value :name, 'bob'
web.enter_value :password, 'secret'
web.press_button :login
assert_that web.current_page, has_title("Welcome")
end
Now we monkey it up, with the keywords usually, sometimes and rarely:
require 'rmonkey'
include RMonkey
def test_user_can_login
navigate_to '/login'
usually { web.enter_value :name, 'bob' }
sometimes { web.enter_value :name, 'kate' }
rarely { web.enter_value :name, random_string() }
usually { web.enter_value :password, 'secret' } # sometimes don't bother
web.press_button :login
sometimes { 10.times { web.press_button :login } } # bored bored bored!
assert_that web.current_page, has_title("Welcome")
end
So now you have automated monkey tests. There are default probabilities for usually/sometimes/rarely (say 80%, 15%, 5%) but that is customizable:
monkey_see :usually => 75, :sometimes => 22, :rarely => 3
The interesting part, of course, is to know what sequence of events leads to a test failure. A more fully-featured RMonkey would keep track of which events it executed and produce an informative narrative if things turned bad.
In the spirit of the infinite monkeys metaphor, this would prove most useful in a soak-testing scenario, whereby thousands of monkeys were hitting an application over an extended period of time. You would want to know that a) mostly it worked, and b) when it didn’t work, which sequence of events caused it to break.
Some obvious applications for RMonkey would be in driving Selenium or Watir, or using JRuby to drive JUnit, MarathonMan, WebDriver or any of the other Java testing frameworks.
The code for rmonkey.rb is simply:
module RMonkey
LIKELIHOOD = { :usually => 80, :sometimes => 15, :rarely => 5 }
def usually
yield if rand(100) < LIKELIHOOD[:usually]
end
def sometimes
yield if rand(100) < LIKELIHOOD[:sometimes]
end
def rarely
yield if rand(100) < LIKELIHOOD[:rarely]
end
def monkey_see(likelihood)
LIKELIHOOD.merge(likelihood)
end
end
So anyway, let me know if you would like to get involved in developing RMonkey. I think it's a really appealing idea and I'd love to see someone do something with it.
