Attended the Melbourne Ruby User Group tonight. I was impressed by the turn out, openness and quality of the discussion.

As much as I’m for gathering knowledge in a variety of languages, come along, learn something and share your experiences.

What is Behavior Driven Development (BDD)?

According to behaviour-driven.org BDD was born from NLP experiments (astonishingly, nlp.com mention NLP and hypnosis in the one sentence!).
It is a combination of TDD and DDD. Here are some of my attempts at describing BDD:

A process for describing the behavior of a system that is understood by both technologists and non-technologists.

DDD applied to the domain of TDD.

The concept of a ‘vocabulary for describing behavior’ is at its core, but interestingly the behavior-driven site falls short of defining the vocabulary (note the incomplete links at the base of this page).
BDD is strongly linked to TDD as tests are often used to describe the features, or behaviors, of a system. Consequently, part of BDD involves writing tests using the vocabulary.

Enter RSpec

That’s the driving principle behind RSpec. Test::Unit is perfectly fine for defining tests, but it doesn’t employ a BDD vocabulary.
RSpec does, and it throws in a side order of Mock and Stub support often needed for TDD. As it happens this support is virtually identical to that provided by Mocha.
Take your pick, the support both provide is particularly cool as you can Mock and Stub methods of any object, sure you can create Mock and Stub objects (in a fashion that I’ve been used to with EasyMock and JMock) but the object doesn’t have to be a Mock or Stub in order to Mock or Stub a method invocation.
To highlight this here’s an RSpec demonstration applied to a banking model;

  describe Account do

    before(:all) do
     @@amount = 100
    end    

    before(:each) do
      @account = Account.new
    end

    it 'should withdraw cash via a Transaction' do
      Transaction.should_receive(:deduct).with(@account, @@amount)

      @account.withdraw @@amount
    end

    it 'should log unsuccessful operation when withdraw is unsuccessful' do
      Transaction.should_receive(:deduct).with(@account, @@amount).and_raise(InsufficientFundsException)

      @account.should_receive(:log_outcome).with(:unsuccessful)      

      @account.withdraw(@@amount).should_raise(InsufficientFundsException)
    end

  end

Pretty cool huh?! This mocks two methods in a manner that can’t be easily repeated with Java:

• A class method, Transaction.deduct
• An instance method of a real object, @account.log_outcome

Take a look at the recently tweaked documentation on the RSpec site for info on it’s other features (like partial argument matches), and more generally its implementation of a BDD vocabulary.

Why use RSpec?

One of my initial encounters with RSpec was via a blog critising BDD that goes so far as to suggest RSpec is pronounced ‘arse peck’, so I’ve been skeptical from early on. I have been particularly cosy with XUnit tests, a mock framework and consistent test method naming conventions as a way of specifying behaviors, so I didn’t feel the urge to change. Test::Unit and Mocha can pretty much yield the same result - what did I have to gain?

Still, this ol’ school approach requires some discipline and custromizations to read like a BDD vocabulary. RSpec, on the other hand, encourages codification of tests in a consistent BDD vocabulary. But hey, if you don’t intend on using the vocabulary for communications between roles (and that’s a substantial change) your missing the major benefits of BDD - so why bother?

Nonetheless, it’s worthy of consideration.

With its subtle shift in the XUnit language I believe it produces more readable tests. That coupled with its nice mock and stub support and the potential benefits of a shared language for describing behavior - the pro’s start outweighing the con’s.

Parting Thoughts

I’ve read some BDD proponents claim they sought out BDD as a solution to tests that are tightly coupled to source, hindering refactoring and causing a maintenance burden.
I fail to see how BDD helps here; this is a natural consequence of writing unit tests. For tests to do their thing, an API under test must be invoked - you can’t avoid that. If you change that API; surprise, you’ve got to change your unit tests! If you’re suffering this affliction maybe you should test against an API few layers up, like HTTP. Personally though I’d be blind without my unit tests, at a minimum they aid design and verify correctness.

Admittedly I’ve been caught in the community currents moving towards Ruby and Rails development triggered by the Pragmatic Programmers. While on the ride I’ve been weary of their seemingly direct competitors, Python and Django.
The choice of which to use has usually been an emotion charged debate.

While others have poked around and performing comparisons, I thought I’d take a quick look for myself.
There are two comparisons at play here which I’ll split into two entries: Python vs. Ruby, Django vs. Rails.

Here’s my take on Python vs. Ruby. Granted it’s a long way off comprehensive, biased by my knowledge of Ruby.

Ruby

Pro’s

• Everything is an object
• Method discovery built into the language
• Language reads more naturally, take optional parenthesis as an example
• ! and ? methods suffixes are a nice standard for communicating intent
• return optional
• More object focused
• Often more readable
• IntelliJ IDE support

Con’s

• Slower
• Less Mature

Python

Pro’s

• Blocks via indentation more terse
• Class methods can be easily treated as function objects
• No need for @, @@, $ as namespaces are used
• Method arguments can be passed by name
• Automatically generates compiled scripts for efficiency

Con’s

• pass required for empty blocks
• Parenthesis required on method calls
• self required as first argument to methods
• return required
• Verbose import statements, e.g. from package.subpackage.module import class, class.method.
• Why import an individual method or variable?!
• Is from datetime import datetime DRY?!
• Less object focused, attributes are also first class citizens
• Method documentation (docstring) within method doesn’t aid readability
• Method default values are only evaluated once and reused in subsequent calls
• Non-OO approach to sequence manipulation and list comprehensions with methods such as map, del, sort and sorted
• Dictionaries throw an exception when key not found
• No concept of scope, class internals completely exposed. Use convention (such as underscore prefix) to suggest scope
• Ruby has Rake and Python has ?!

Weird stuff

• zip is an unusual name for iterating over multiple sequences
• Comparison chaining is unorthodox, i.e. 1 < 2 == 2
• ‘Isn’t’ produces the string “Isn’t”. However ‘Isn’t”‘ produces the string ‘Isn’t”‘. In the latter case a backslash remains and the start and end quotes are different.

Similarities

• The languages feel remarkably similar. They both seem as terse.
• Gem’s and Egg’s
• JRuby and Jython
• IronRuby and IronPython

Other discussions of Ruby vs. Python:

• Python up, Ruby down: If that runtime don’t work, then its bound to drizzown
• Should I Learn Python or Ruby next?
• Ruby, Python, “Power”
• Ruby vs Python - it’s a pointless argument