BDD is not about tools

My team had to integrate with a third party tool whose client library was written in javascript. In order to prevent sprinkling dependency dust all over our code base, we isolated our integration point in a gateway object. After a little research a few members on our team decided that they wanted to test drive the code using Blue-Ridge, which includes ScrewUnit. They felt that this library was very comprehensive and pretty stable. However, when it came time to write some tests, I was really not looking forward to introducing this tool into our codebase.

Screw.Unit is a Behavior-Driven Testing Framework for Javascript. It features nested describes. Its goals are to provide: a DSL for elegant, readable, organized specs; an interactive runner that can execute focused specs and describes; and brief, extensible source-code.

As I understand it, BDD is TDD that is well factored and uses an expressive vocabulary. Dan North started changing the way he thought about writing unit tests so that they were readable and make it easier to teach others unit testing.   

I also thought it [JBehave] would be a valuable teaching tool for introducing TDD and BDD without the distractions of the test-based vocabulary.... Chris and I realized we were trying to define a ubiquitous language for the analysis process itself! http://blog.dannorth.net/introducing-bdd/

In my opinion these tools don't do anything special, they simply attempt to provide a template for developers to write structured unit tests. I personally also find the syntactic sugar, a.k.a DSL, of most of these frameworks to be confusing and inconsistent, which runs contrary to what Dan was trying to do with JBehave:

#xUnit

#-------------------
def test_new_accounts_should_have_an_initial_balance_of_zero
  account = create_new_account
  assert_has_zero_balance account
end

#RSpec
#-------------------describe "A new account" do
  include AccountExampleHelperMethods
  before do
    account = Account.new
  end
  it "should have a balance of $0" do
    helper_method
    @account.balance.should eql(Money.new(0, :dollars))
  end
end 

Is Ruby's Test::Unit::TestCase inferior to RSpec? Was the RSpec test somehow clearer and more expressive than the xUnit version? I claim that these frameworks do not magically lead you to a utopia of ubiquity and expressive code. Writing good, clean, valuable code is a skill.

Templates are good but great code is better...