Thanks Chris. This is a really nice description of how I think of BDD. I call it "we should fix that" after Liz Keogh's blog post: http://sirenian.livejournal.com/42871.html
(Check the comments for the myriad ways you can misinterpret this!) Cheers, Dan On 04/03/2008, Chris Parsons <[EMAIL PROTECTED]> wrote: > > On 4 Mar 2008, at 13:13, Matthijs Langenberg wrote: > > > Taking the outside-in approach in thought: > > > > At first we write a high-level customer-facing story, this story > > fails. > > Then we start using mocks at object level to use them as a design > > tool, > > and so we implement the different layers of the system. > > After implementing the inner layer, the story should pass. > > When that happens we could remove the mocks and replace it with > > calls to the real code, making the suite less brittle (except for > > calls to external services/databases/file systems). > > > Don't use mocks at the story level. IMHO stories should always be > using the full stack. This includes your database, but you might be > permitted to exclude external services such as credit card billing > systems. However, if you can set up a sandbox to test against (such as > the Paypal sandbox), all to the good. > > We proceed based on two principles: > > A failure in a story means you change specs not code. > A failure in a spec means you change the code. > > This is how we do it (assuming a rails application): > > 1. Write customer story, all steps are pending: > > Scenario: Viewing the front page > When I view the front page > Then I see the text 'welcome to the app' > > 2. Write the first step in the story: > > When "I view the front page" do > get "/" > end > > This then fails, as I don't have a front page yet! > > 3. Pay attention to the error given by the story, and fix that *by > writing a spec*. > > In this case it'll be complaining that the controller doesn't exist. > At this point I drop down to the specs as a failing story means we > need a spec: > > describe MainController do > end > > 4. Make your specs pass. > > 'rake spec' then fails, as MainController doesn't exist. In this case, > I add a controller and a route (by hand, none of that scaffold > business): > > class MainController < ApplicationController > end > > 5. Run the story again if you need to, and use that as a guide to > write more specs. Repeat steps 4 and 5. > > To continue the example - in this case it'll probably complain about > no index action: > > describe MainController do > it "should handle an index action" do > get :index > end > end > > and then, to fix the spec: > > class MainController < ApplicationController > def index > end > end > > Then it'll most likely complain about not having an index.html.erb. > Because controller specs don't render the page, you'll need an an > index.html.erb_spec.rb to test the view properly. And so on. > > Sound like a lot of work, but given practice you can zip through these > steps very quickly. You also get a free 'focusing tool' (lose sight of > where you are? just run the story test and write more specs). > > Hope this is helpful. Maybe I should write up an extended example as a > blog post, including mocking etc, as it seems to come up a lot. > > Thanks > Chris > > PS: Excuse the spelling/coding mistakes in the (untested) code :) > Corrections and comments as to the methodology here most welcome. > > -- > Chris Parsons > Managing Director > Eden Development (UK) Ltd > > [EMAIL PROTECTED] > www.edendevelopment.co.uk > > 0845 0097 094 > po box 425, winchester, so23 0wy, uk > Map: http://pininthemap.com/edendevelopment > > > Tried Pin in the Map? Mark a map location, add text, send to friends. > http://pininthemap.com > > This electronic message and all contents contain information from the > sender which may be privileged, confidential or otherwise protected > from disclosure. The information is intended to be for the > addressee(s) only. If you are not an addressee, any copying, > disclosure, distribution or use of the contents of this message is > prohibited. If you have received this electronic message in error, > please notify the sender by reply e-mail and destroy the original > message and all copies. The sender does not accept liability for any > errors or omissions. > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
