[rspec-users] stepping across features

Andrew Premdas apremdas at gmail.com
Fri Dec 5 11:42:53 EST 2008


Pretty hard for me to comment with so much stuff and so little context.
However :)

Your telling an epic story involving work orders, charges (unbilled released
and billed), invoices and transactions. So what are all these things and
what is the business value of them, can we right more focused and simpler
scenarios. Perhaps if we do stuff to create work orders we will get steps
we can nest so we can create a step like

    Given a work order with outstanding charges

So we get better tools to deal with our more complicated scenarios as we go
along

Each scenario should be about one thing Work Order Completed has all sorts
of things going on with it so the scenario needs to be split up into smaller
ones

Your feature says its about "producing invoices" yet it seems to be all
about work orders

You've got lots of assumptions about how things are done, I can almost see
the legacy application in front of you. Why should you have to even think
about a work order to produce invoices. You have to do some design and
thinking to produce good features. Challenge assumptions and try and see
things from different view points. For example why can't I just do

Given outstanding payments
When I visit the make invoices page
I should see a list of invoices I can create

And then do some other little scenarios to create an invoice etc..

HTH

Andrew

2008/12/5 James Byrne <lists at ruby-forum.com>

> 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
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081205/0a040396/attachment.html>


More information about the rspec-users mailing list