Andrew Premdas wrote:
> James,
...
>
> So back to your original question where does all the detail go? Well
> acceptance tests start from the general and go to the specific, so
> detail comes further down some sort of heirarchy. Thing is you
> haven't got a hierarchy yet so you don't know where to put things.
...
As I learn best from examples, let us consider a fairly common feature
of a business application:
Feature: Produce Invoices
In Order to: Bill Chargeable Work
An Invoicing Clerk
Should be able to Produce Invoices
To Increase Revenue
Scenario: Work Order completed
Given work order "X" for client "Y"
And work order "X" is completed
And work order "X" has "N" unbilled charges
And "all" charges have been released for billing
When I view work order "X"
Then I should see "N" unbilled charges
And I should be able to select "all" unbilled charges
And I should add "N" charges to a new invoice
And the new invoice should have a unique transaction number "Q"
And invoice "Q" should have client "Y" as the bill to party
...etc.
Scenario: Work Order open
Given work order "X" for client "Y"
And work order "X" is not complete
And work order "X" has "N" unbilled charges
And "M" charges have been released for billing
When I view the work order
Then I should see "M" unbilled charges
And I should be able to select "M" unbilled charges
... etc.
Now, we have two cases, an open and a closed work order, both producing
new invoices. How does one proceed to decompose this to also cover the
case where one adds the charges to an existing, open, invoice; or the
case where "N" billable charges are listed but only "N"-"M" charges are
to be billed? Do you create more scenarios in the existing feature
file or create new feature files for these scenarios? If the former
then how does one avoid having scenarios that themselves are filled with
compound conditional statements; or. is this OK? If the latter, how
then does one relate high level feature files with their descendants?
Similarly, how much detail goes into the creation of an invoice in this
case? Do you break out invoices features into specifying the bill-to
party, forms of items to add to the invoice body, payment terms, tax
calculations, etc.? Are these individual features?
I realize that this is a styling issue but the spectre of Worf/Sapir
haunts such choices.
--
Posted via http://www.ruby-forum.com/.
_______________________________________________
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
