An interesting opinion (which I’ve slightly mischievously taken out of context here) from the article:

In fact, I’m not sure if Java the language is good enough for anything, anymore.

That's so ugly, it almost looks like Java. Actually, it's worse than Java, which has String#equalsIgnoreCase.

However, there's one disadvantage that duck-typed languages suffer when it comes to using mocks to drive the design of the interfaces between objects.

The following example is lifted from the excellent paper Mock Roles, not Objects, by Steve Freeman, Nat Pryce, Tim Mackinnon and Joe Walnes. If you haven't already read it, it's well worth it.

Here's a test case:

And here's some code to pass the test:

In order to get this to compile¹, you also need to introduce an interface:

When you've finished specifying the behaviour of TimedCache, you simply move on to an implementation of ObjectLoader, and repeat the process.

Now here's something similar in Ruby. First the test:

And the code to make it pass:

The difference here is that Ruby doesn't have interfaces. The mock object loader is just an object of no particular class, with a bunch of methods on it (OK, just the one in this case), which you then have to remember to include in the real implementation.

I wonder whether it would be useful to be able to print out a list of the methods that you've mocked, to give you a starting point when implementing the classes you've mocked. Here's a very quick-and-dirty hack to Spec::Mocks::Proxy that prints a list to the console while the test's running:

Here's the output:

An object that is not cached
  mocked on loader:
    load(1)
    load(2)
- should be loaded

Really this probably belongs in a custom formatter, but it doesn't look like the right hooks currently exist to implement it that way.

Technorati Tags: bdd, mocks, ruby, rspec

Apparently there are more coming over the next few days.

As you might expect from the name, CruiseControl.rb performs a similar function to CruiseControl (Java) and CruiseControl.NET, but is written in Ruby (it's actually a Rails application). From a quick play it looks to have quite a few advantages over the original (I've never had cause to look at the .NET version):

• At least as easy to get started with as the binary distribution of CruiseControl.
• Ludicrously simple to add a new project (just tell it where the repository is).
• Builds Rails applications with no configuration.
• Only needs a one-line config change to build anything &ndash not just Ruby – as long as there's a single command to do it.
• Clean, AJAXified user interface.
• Publishing artifacts is as simple as making sure the build drops them into the directory specified by$CC_BUILD_ARTIFACTS.

As an aside, it also shows that Rails isn't just useful for building database-centric applications.

It all looks so simple that you wonder what's missing, but it seems to do everything most people need from a continuous integration server. Anyone who's using Subversion and doesn't need to run a huge distributed build should at least have a look – all that complicated config.xml editing could be a thing of the past!

Technorati Tags: continuous integration, cruisecontrol, build, ruby

Imagine you're implementing a customer support system where people can submit a problem report along with their phone number, and you want to have the appropriate person ring them to help resolve their fault. Your system does whatever magic is required to find who that appropriate person is, then uses the Web21C SDK to set up the call:

The ThirdPartyCall constructor on line 12 takes two arguments, callee and caller. When the call is connected using startCall(), the caller's phone (the engineer, in our example) rings first. Once they pick up, the callee's phone starts ringing, and the call between the two is connected as though it had been made directly (although neither party sees the other's caller ID).

The SDK is in public beta, and is currently free (with daily usage limits). Up to now it's only been available for those crazy .NET folks, but the next release (on Monday, all being well) will extend that to Java, PHP and Python. Rumour has it that Ruby's in the works too.

I've been having a play with the Java version – here's a sneak preview...

There are a few steps to get set up. First you need to create an account on the website. You then need to download and run a Java application to register your application and create a certificate to identify you to the underlying services. Then there are a few JARs to put in your classpath, a properties file to update with your username, password and certificate filename, and you're ready to go.

For example, this is all you need to write to send a text message:

Pretty self-explanatory, and just to prove it works:

Technorati Tags: web21c, bt, sdk

So far all I've got is a very simplistic and slightly messy spike, which I'll describe here. I've deliberately avoided tying this in to a particular framework (I've used JUnit 4) or forcing test classes to extend a specific base class, so it should be equally applicable in TestNG, LiFT etc, and with other tools such as XMLUnit, EasyMock, JMock or Hamcrest.

There's nothing clever going on here, and it's far from the elegance of something like rspec – partly because of Java lack of things like closures, and partly because of my limited talents.

For this example, I've used a few trivial tests for the Stack class. I'm going to use a single given (the precondition or setup for a test or set of tests), a couple of whens (events whose effect you're testing/specifying) and several thens (assertions/specifications of expected behaviour). Because the setup is part of the given, I'm not using JUnit's built-in test setup capability. I'll show the example first, then the code behind the scenes. If you like, the whole thing (such as it is) is available as givenwhenthen.zip.

Example

First, here's the basic test class, to show there's nothing up my sleeves:

Now the given (an newly-created Stack object):

OK, I already warned you it was a bit messy. Now some whens, specifying things that can happen to the new stack:

And finally the important bit – the thens containing the assertions:

These are hopefully relatively readable.

Implementation

The code to support this is contained in two small classes: Given and When.

Here they are, with hopefully enough comments to explain how they work (it's hardly rocket science anyway!):

Reporting

The classes above generate a report of the specifications. For the spike, this is just spewed out to the console as plain text, but a real implementation could use any destination or format.

Here's the output from the example tests:

Given: a new stack
When:  an item is pushed
Then:  the stack should not be empty

Given: a new stack
When:  an item is pushed
Then:  the stack should have a size of 1

Given: a new stack
Then:  the stack should be empty

Given: a new stack
Then:  the stack should have a size of 0

Given: a new stack
When:  an item is popped
Then:  an EmptyStackException should be thrown

Limitations

Obviously there are many! Off the top of my head:

• It's not particularly elegant (especially the given and when declarations)
• There's duplication between variable/method names and the descriptive strings
• The spec list doesn't highlight failures

Any comments or suggestions welcome!

Technorati Tags: tdd, bdd, agile, junit, testing

[Update:] I've simplified the import of java.util.Date following a suggestion in a comment (from Charles Oliver Nutter, no less!). I also noticed that I wasn't using rspec's setup properly (or at all), so I've tweaked the samples a little. I haven't got the code here to try out, so there may be typos.

Getting rspec installed in the jruby environment was a simple case of downloading the gem and installing it using the jruby gem command. This installs a spec command in $JRUBY_HOME/bin, but no corresponding spec.bat wrapper. If you're unfortunate enough to be using Windows (as I was, being at work), it's trivial to copy one of the existing wrappers and change the command it runs. I had to use the wrapper script to run the specs from ant, because I couldn't get it to work by using org.jruby.Main directly (probably just user error – I didn't bother investigating much as I was only really interested in the specs themselves).

To get a direct comparison, I concentrated on reproducing an existing junit test, rather than trying to use rspec to do some actual TDD/BDD. I suspect this was slightly harder than it would have been to have used rspec while I was writing the class in the first place, but was still surprisingly painless (particularly as my ruby's a bit rusty).

Comparisons between equivalent junit and rspec code

Here are a few 'compare and contrast' excerpts from the two files. I've removed a few bits and pieces that weren't really relevant to the examples, and changed a few minor things round in the java to make for a better comparison.

Preamble

Nothing particularly noteworthy there. There are a couple of extra imports in the ruby version which weren't required in Java because the test class was in the com.bt.csam.pieman.domain package. If there had been more, it would probably have made more sense to just do include_package 'com.bt.csam.pieman.domain' and grab the lot.

The import of java.util.Date has been aliased to JDate, because it would otherwise clash with Ruby's Date class.

Constants and setup

Again, very similar. I chose to declare the log object locally to each context in the ruby version, which is why it's missing from the global setup.

The first test/spec

That was painless (once I'd figured out whether to use should.be, should.eql, should.equal or should ==). My first attempt used @log.getCreatedBy, but I wondered whether it would call the getter automatically, and sure enough it did.

Working with dates, collections and booleans

The date stuff would all have been a lot easier if the class had used an external mockable time source, which is a technique suggested in Mock roles, not objects [PDF]. This is one of those things that seems obvious once you've seen it (which is always after you've spent ages working around the same problem the hard way).

Anyway, reproducing the existing tests:

I expect there's a better way than faffing about with java Date objects, but it's not too bad as it is. Note that setLatestDealingStartTime is called automatically, the same as the getters.

For boolean values, the behind-the-scenes magic works again, and @log.should.be.currentVersion acts like assertTrue(log.isCurrentVersion()) (only more readable). Once again, ruby passes Arthur C Clarke's sufficiently advanced technology test.

Finally, the rspec should.be.empty (and similar constructs) all work seamlessly with java collections too.

Human-readable spec output

Here's the output from running the original junit report through a stylesheet:

Abstract pieman log

• created by set on create
• modified by by set on create
• timestamp set on create
• get title prefixes
• current version on new object
• status defaults to open
• newly created log has latest dealing start time equal to create time
• newly created log has dealing clock running
• newly created log has zero stored dealing time
• dealing clock not running after stop dealing clock
• dealing clock running after start dealing clock
• stored dealing time set to seconds since latest dealing start time when dealing clock stopped for the first time
• latest dealing start time set to current time when dealing clock started
• latest dealing start time set to null when dealing clock stopped
• dealing time formatted as colon separated hours minutes and seconds
• seconds since latest dealing start time added to stored dealing time when dealing clock stopped after the first time
• stopping clock when already stopped has no effect on dealing time fields
• starting clock when already started has no effect on dealing time fields
• dealing clock stopped when log is closed
• dealing time equals stored dealing time when clock stopped
• dealing time equals stored dealing time plus time since last start when clock running
• cleared time always equals closed date

And here's the rspec equivalent:

A newly-created log
- should be timestamped with the creation time
- should be marked as created by current user
- should be marked as modified by current user
- should have no title prefixes
- should be the current version
- should be open
- should have the dealing clock running
- should have the latest dealing clock start time set to its timestamp
- should have no stored dealing time
A log after the dealing clock has been started
- should have the dealing clock running
A log that has the dealing clock stopped after five minutes
- should not have the dealing clock running
- should have a stored dealing time of five minutes
- should have a latest dealing clock start time of null
- should ignore further attempts to stop the clock
A log that has the dealing clock stopped after five minutes and already has a stored dealing time of ten minutes
- should have a stored dealing time of fifteen minutes
- should display dealing time as 0:15:00
A log that has the dealing clock stopped after five minutes then restarted
- should have a latest dealing clock start time of the current time
- should ignore further attempts to start the clock
A log that has had the dealing clock running for five minutes and has a stored dealing time of ten minutes
- should display dealing time as 0:15:00 (ish)
A log with the clock stopped and a stored dealing time of one hour 23 minutes 45 seconds
- should display dealing time as 1:23:45
A closed log
- should not have the dealing clock running
- should have a cleared time matching the closed date

I don't think there can be much debate about which is more readable.

Where's the when?

A couple of months ago, Dan North made this comment on the subject of rspec:

I’m a big fan of Ruby, and I like some of the ideas behind rspec. However I’ve been working with Niclas Nilsson on a Ruby port of JBehave called RBehave, which we think conveys the intent of BDD more clearly.

At the time I wasn't sure quite what he meant, but having been to the Awesome acceptance testing session that Dan ran with Joe Walnes at XP Day 06, I realised how useful the given...when...then approach to behaviour specification is. Unfortunately rspec only has two levels – context and specify.

One of my specs (in English: when a log is closed, the clock should be stopped) ended up like this:

That's effectively moving the when into the given. The alternative would have been to move it into the then, but then it ends up duplicated in two specifications :

Neither of these seems quite right. It would be nice if you could have one or more events per context, with one or more specs per event. The above would then become something like this (I've added an after rather than going with given...when...then, partly because when and then are reserved words):

Of course, I've only dipped a toe into rspec, so maybe it supports that kind of structure already.

Technorati Tags: jruby, rspec, junit, agile, testing

Still, an as-yet-unknown new project beckons in the new year, so who knows?