Behavior-driven development

Despite the obvious benefits of automated acceptance tests, in practice, even amongst experienced XP and TDD teams, it's rarely done, or done well. One of the reasons is that finding a stakeholder with the technical ability, interest, and patience to sit in front of a computer writing pure code for even a DSL like gerkin or RSpec is hard. Consider the following rspec test present in WEBrick (an HTTP server in Ruby commonly used in development):

  should "be a WEBrick" do 
    GET("/test") 
    status.should.equal 200 
    response["SERVER_SOFTWARE"].should =~ /WEBrick/ 
    response["HTTP_VERSION"].should.equal "HTTP/1.1" 
    response["SERVER_PROTOCOL"].should.equal "HTTP/1.1" 
    response["SERVER_PORT"].should.equal "9202" 
    response["SERVER_NAME"].should.equal "127.0.0.1" 
  end

This example observes the behavior that is based on the response from the server, from this it can be concluded that the server is a WEBrick server or not.

However, at time this may...