Latest on twitter:
RubyConf 2007
TDD is incremental, drives implementation, should focus on design, documentation, behavior, and result in an exhaustive regression test suite.
Chelimsky and Astels are going to live program using ping-pong pair programming.
Dave Astels is giving the history of BDD. He followed the early days of TDD as Kent Beck articulated it. In 2004, Dan North and Aslak Hellesay (Thoughtworks London office at the time) began discussions around “BDD: it’s all behavior”. They thought about the ability of Smalltalk and Ruby to embed these ideas into the language. In August of 2005, RSpec began with Steve Baker’s work, was moved into RubyForge. David Chelimsky got involved in early 2006, the November 2006 release was considered the “eat your own dog food release.” In May, 2007, they released 1.0.0. This year, more projects have begun shipping with it by default, notably JRuby and Rubinius. This month (November, 2007), they will include the Story framework and begin to include Test::Unit compatibility? (Why are they starting so late?)
RSpec has been straddling the line between being customer-oriented and developer-oriented. Until recently, Chelimsky’s opinion was that the customer-oriented side was lacking.
At first, BDD was considered “should” instead of “assert”. That’s wrong. It has developed into a complete Agile process.
Customer acceptance tests. Domain-driven design (Eric Evans). In Extreme Programming, there is the idea that the client and developer get together and the client describes the system at the beginning of the iteration. In the meeting, you do “acceptance test driven planning”, breaking down the stories into specifications. The developers write code until those specs pass, which is considered “acceptance.”
It’s an outside-in process. Start by specifying at the highest levels. Chelimsky specs out the views in his Rails apps. The mocks tell him what he has to build at the lower levels.
The Story Framework. We want documentation that is tied to the system. With TDD, the original thinking was that the tests are an executable description of the system. The problem is, they were written in Java or Ruby or otherwise and not written for the customer. That was the emphasis behind a tool called Fitness. Kent Beck created it with the idea that the customer can write the specs.
Mike Cohen, “User Stories Applied” … Story do … end … The last bit in their example of the Story description listed the business value, which is a crucial component.
Stories have Scenarios. Scenarios blocks have Given, And, When, Then constants/blocks.
Chelimsky is showing a web-based interface that allows customers to add steps to a spec and run immediately against the system.
The spec framework has mocking built-in as a first-class citizen. It has clear reporting. It has integration with autotest and heckle.
Showing the different ways to do pending specs. it “label” without a block. “pending” in the block, pending(“because I’m waiting for feedback from the client”), shows in output.
Rubinius uses minirspec. Rumor has it that miniunit willsoon ship with minirspec. The combo will also ship with Ruby 1.9.
They are moving bug tracking to Lighthouse, maybe source control to git.
“Behavior Driven Development in Ruby with RSpec” ~ Pragmatic Programmers. Pat Maddox is also writing an RSpec book with Addison-Wesley.
Ryan Davis is criticizing RSpec for … being a DSL? … not being transparent enough to Ruby programmers? He is “comforted by def, knowing it is a method”.
