Bit of a ramble, but see inline comments.
Cheers,
Dan
2008/11/7 Joseph Wilk <[EMAIL PROTECTED]>
> David Chelimsky wrote:
>
>> On Fri, Nov 7, 2008 at 9:58 AM, David Chelimsky <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>> On Fri, Nov 7, 2008 at 9:54 AM, Matt Wynne <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>> One technique is to have a single noisy 'declarative' scenario that
>>>> explicitly walks around filling things in, then all the rest use more
>>>> 'imperative' style steps where most of the detail is buried away.
>>>>
>>>>
>>> You've got those backwards :)
>>>
>>> declarative: when I fill in the form correctly
>>> imperative: when I enter "David" in the "Name" field ....
>>>
>>>
>>
>> Although - maybe we need to reconsider this naming, because you could
>> argue that either are declarative, whereas imperative, meaning
>> important/urgent, doesn't really convey the explicit nature. I think
>> abstract/concrete could work. Maybe general/specific.
>
>
I agree with abstract and concrete, and in fact this is where scenarios
first came from. A business analyst thinks in abstract terms ("we're going
to have to be able to withdraw cash"), and the tester's job is then to map
that to concrete examples ("start with $100, request $80, make sure we get
$80 and have $20 left in the account"). The tester's description will
necessarily be finer grained.
The scenario title should be at the analyst (more abstract) level of
granularity: "withdraw funds from an account with sufficient balance"
The imperative/declarative terminology is a bogus one. Imperative means
"how", and declarative means "what". Any level of abstraction is both a how
and a what depending on your perspective. There's an exercise you can do
with any statement to demonstrate this. Simply ask "how?" to move down the
stack of abstraction or "what for?" to move up. It's turtles in both
directions. Here's an example:
SQL is the canonical example of declarative, so:
select count(*) from accounts where balance < 0
But if I ask "what for?" I get:
find out how many accounts are overdrawn ("more" declarative)
What for?
calculate our exposure to dollar fluctuations
What for?
what is our operating risk in the current financial climate
What for?
... etc
Now going the other way:
select count(*) from accounts where balance < 0
How?
set up a counter variable, then scan the accounts table and increment
whenever you see a negative balance
How?
cue up a number of subtasks that will scan segments of the accounts
table, then aggregate the results
How?
... etc.
Having said all that, it's important to be able to define your own
abstractions over the operations you carry out in your application. "Login
as Dan" is a sensible chunk to have a conversation about. At that point I
would probably use ruby methods to aggregate multiple steps into
coarser-grained abstractions.
Of course each of these abstractions tells you something new about your
domain, and in that regard it has value to someone coming along later and
reading your examples. ("These three steps always seem to occur together -
perhaps we should have a name for that".)
Cheers,
Dan
ps. David is right - the list-of-instructions is imperative, the what-I-want
is declarative.
>>
>> Other ideas?
>>
>>
>>
>>> Cheers,
>>> David
>>>
>>>
>>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>>
>>
> I like abstract/concrete
> My other suggestions:
>
> * Explicit / Implicit
> * High level / Low level
> * Coarse / fine
>
> --
> Joseph Wilk
> http://www.joesniff.co.uk
>
> _______________________________________________
> 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
