This post originated from an RSS feed registered with Ruby Buzz by Obie Fernandez. Original Post: Design Trumps TDD Feed Title: Obie On Rails (Has It Been 9 Years Already?) Feed URL: http://jroller.com/obie/feed/entries/rss Feed Description: Obie Fernandez talks about life as a technologist, mostly as ramblings about software development and consulting. Nowadays it's pretty much all about Ruby and Ruby on Rails. Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Obie Fernandez Latest Posts From Obie On Rails (Has It Been 9 Years Already?)

Saturday at RubyConf 2005 was awesome. Among other things, Jim Weirich gave his inspiring talk on domain-specific languages (DSL) and Steve Baker and Aslak presented information about RSpec and behavior-driven development (BDD). As mentioned in a previous post, the discussion on BDD turned into a lively mocks versus stubs debate and carried over to dinner time where I was very happy to get to know Nathaniel Talbot, a skilled Rubyist. To make a long story short, as the debate carried on I started figuring out that there are significantly better ways to achieve the goals of RSpec in Ruby, as long as we remember that Ruby is not Java. Sounds obvious right? Ha! It isn't if you're a Java guy relatively new to Ruby programming.

Dinner ended. There was still some time before the Matz keynote. So Aslak and I sat together at the rear of the room and did a bit of pairing on RSpec code. And that's when it all started to really click in my head. Don't want people to do TDD with a testing mentality? Then we have to dump the JUnit/TestUnit legacy code patterns and all the testing mentality that comes along with them. And you know what else, while we're at it let's go ahead and deprecate the term TDD.

TDD was a bad term from the start, because it doesn't make logical sense to test something that doesn't exist. And as plenty of folks have been saying lately, most programmers don't get TDD at all. Well, okay there's probably a reason for that. I'm trying to say is that we need a term (and libraries too) that facilitates design-driven development. It's a concept that I believe, compared to TDD, a significantly larger percentage of the mainstream programmer population will understand and be happy to adopt.

Getting back to my story about Saturday, Aslak and I didn't have much time to pair, but I managed to communicate to him a story/actor/scenario metaphor and a very rough format for the corresponding DSL. Here is a refined proof-of-concept that I wrote this morning. The example domain is based (loosely) on the Payroll Case Study in Bob Martin's Agile Software Development. Notice the different vocabulary, emphasis on DRY, and usage of Rails-style magic. No more methods_with_long_descriptive_names_that_describe_the_test_case. Actual strings works so much better, don't they? Finally, in case it's not obvious, implicit assertions happen throughout the scenario block. Feedback welcome.

payroll.spec

actors :audits => Audit::Logger,
       :db => PayrollDatabase,
       :employee => Employee,
       :transaction => Transaction
 
story "A new employee is added by the receipt of an AddEmployee message." do
 
  Name = "William Jones"
  AnnualSalary = 60000
  MonthlySalary = 5000
  MonthlyType = Employee::Monthly
 
  scenario "add a salaried employee earning 60k per year" do
 
      db.pretend! do
        on_create :with => (:name => Name, :salary => AnnualSalary),
         :return => Employee.new(Name, MonthlyType, AnnualSalary)
      end
 
      transaction = AddSalariedEmployeeMsg.new(Name, AnnualSalary)
      transaction.execute()
 
      to_verify do
        employee = db.find_by_name(Name)
        employee_classification == MonthlyType
        employee_salary == MonthlySalary
 
        audits_received :log, NEW_EMPLOYEE
      end
 
  end
 
end