I try to thing of the audience for the work, and it keeps me sane.
Stories are to make sure you’re holding up your contract with the
client or user. They are high level, and don’t deal with any
implementation details that can be abstracted away. You might relate
them to acceptance tests, because when you pass stories, you’re
passing all the acceptance criteria. You also might compare them
integration tests, because they should ensure everything behind the
UI (or API) works correctly. It’s reasonable to mock external
services, but I try to have these be as real as possible.
If you and your user disagree about how something works, you make the
change in the story. Then you change the specs and code as needed.
Specs are to make sure you’re holding up your contract with the code
and its developers. With so little static checking in ruby, specs are
your type checking, exception checking (ala java), the preconditions,
postconditions, and invariants (ala DbC), published interface,
performance profiler, and possibly even internal documentation. These
make sure you know the right way to interact with the code. And of
course you should specify the code before you implement it, red-green
style.
If you and a developer disagree about how something works, you make
the change in the specs. Then you change the code as needed.
Clear as mud?
On 02008:02:18, at 5:44CST, David C. wrote:
Specs are aimed at describing the behaviour of the objects in your
The examples in specs, on the other hand, typically come into
From: “Andrew WC Brown” [email protected]
I’ll write a few stories of what I think should it happen.
I constantly step move back and forth.
for using stories and specs. Should I be writing stories first,
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
http:// Joseph Holsten .com