[rspec-users] [cucumber] Cucumber and CI
sfeley at gmail.com
Mon Feb 23 13:15:29 EST 2009
On Mon, Feb 23, 2009 at 11:44 AM, James Byrne <lists at ruby-forum.com> wrote:
> F=31, S=165, PC=100%, TU=30, CU=21, financial services (insurance
Whathuh? Wow, you really *do* work for government, don't you? >8->
That line hurts me to look at and I'm not going to try to put my
answer in that format.
Since I've started using Cucumber I've mostly been doing smaller
projects, and the only ones I've completed or brought near completion
have been personal ones. My last project was a spike that had to be
done inside a week and I abandoned most testing (and it shows), but
apart from that it seems like the projects I consider 'smallish' tend
to have about 10-30 features, with usually 5-10 scenarios per feature.
If I had to think about how feature counts scale, I'd say that in the
most general case they scale by significant models. A "significant
model" is an entity that really matters to the business process (as
in, you can't describe the process without it) and that has a
non-trivial interface. If I'm building a membership registration
system, "Member" is certainly a significant model. "Payment" is
significant. "Phone number" probably isn't, even if I break it out
into a separate table and Rails model for relational reasons.
A significant model will likely have somewhere from 2-5 features
simply by virtue of CRUD operations. You need to be able to view the
information. That's a feature. You need to be able to edit it.
That's a feature too. Whether create/update/delete are separate
features or all one feature varies by how complex or different the
interface needs to be in each case. If it's all one form and that
form has a "Delete" button with a simple yes/no confirmation, you can
probably cover it with one feature. Sometimes you can't. ...And
sometimes there's a need for imports or printed reports or whatever,
and those are all features.
So that's how I gauge this stuff. The driving metric is interface
complexity and the number of different major interactions an actor
could have with the application. I don't know how to gauge "percent
completion" off of that, or why the nature of the industry would be
And... "Total or concurrent users?" That you're asking for that
information totally baffles me. How could that possibly make a
difference to the number of features? That's a scaling issue. An
implementation detail, unrelated to app complexity or business value.
If I wrote an executive information system that only had 15 users, but
those users used it to save millions of dollars, how does the number
"15" help you determine how many features you should write?
Steve Eley (sfeley at gmail.com)
ESCAPE POD - The Science Fiction Podcast Magazine
More information about the rspec-users