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
