Feature Size-Scope-Scale

Testing RSpec
1

The more I work with BDD the more I realize how different this is from
my previous experience. I now consider that part of the difficulty I
have lies in establishing the proper scale for the features that I
propose. My question lies in that vein. What size should a feature be?

I have read a great deal about scaling features in terms of hours of
work. However, at my present level of inefficiency, that will probably
result in features that are too small just as I now believe that the
features I have now are too large. Besides which, I seem to grasp
examples better than metrics when conceptualizing such things.

Returning to my client case. Given that the system must permit
administering clients then does one have a single feature called “System
has clients…” and bundle all the activity related thereto in its
scenarios. Or, as I begin to suspect, should one have separate features
like “Add a new client”; “Deactivate an existing client”; Reactivate an
inactive client"; "Report all active clients; … and so forth.

2

On 2-mrt-2009, at 16:07, James B. wrote:

The more I work with BDD the more I realize how different this is from
my previous experience. I now consider that part of the difficulty I
have lies in establishing the proper scale for the features that I
propose. My question lies in that vein. What size should a
feature be?

It should be big enough to describe the functionality.

Imagine a weblog system, with which a user can post articles.
My typical approach would be 4 features, Creating/Editing/Destroying
and Viewing a post.
Imagine I have validates_presence for the title and contents of an
article.

The Creating feature would have 3 scenarios:

  • Creating an article
  • Creating an article without a title
  • Creating an article without the contents

Updating, 4 scenarios:

  • Updating the title
  • Updating the contents
  • Removing the title (eg, a blank title)
  • Removing the contents

Destroying and Viewing would be just 1 scenario.

I am rather curious what other list members use though…

cheers,
bartz

3

On Mon, Mar 2, 2009 at 10:07 AM, James B. [email protected]
wrote:

I have read a great deal about scaling features in terms of hours of
work. However, at my present level of inefficiency, that will probably
result in features that are too small just as I now believe that the
features I have now are too large. Besides which, I seem to grasp
examples better than metrics when conceptualizing such things.

Real features for a real project I’m working on:

Feature: View Episodes
As a listener
I want to see a list of episodes
So that I can experience the joy of consuming them

Feature: Create Episode
As a podcaster
I want to add an episode
So that I don’t die like Emily Dickinson

Feature: Edit Episode
As a podcaster
I want to edit an existing episode
So that my listeners can catch my mistakes for me

Feature: Add MP3 Enclosure
As a podcaster
I want to link to an MP3 file
So that people don’t confuse me for a blogger

…That’s my basic feature size. An atomic unit of work, and
generally one that comprises a single Web interaction. I’ll usually
put down 2-3 scenarios when I make the feature file (critical success
path, and at least one exception case) and then add more if/when I
think of them.

These mostly fall out to a few hours of work each, but that seems to
be a natural consequence of thinking at an atomic level and not a
deliberate goal I’d planned for. If one of them took days, well, it’d
take days.

[ . . . ] Or, as I begin to suspect, should one have separate features
like “Add a new client”; “Deactivate an existing client”; Reactivate an
inactive client"; "Report all active clients; … and so forth.

Here would be my suggestion:

  • Start by doing it the way you think makes the most sense.
  • If it feels good and seems to result in better code done faster,
    keep doing it that way.
  • If it hurts, or slows you down without a quality increase, either
    try changing the way you’re doing it, or stop doing it entirely.
  • Whenever you next run across something that you think might be a
    good improvement in your working methods, repeat steps 1-3.

Penultimately it’s about people and product. But people build the
product, so ultimately it’s about people. You need to figure out what
works for you and your task at hand. Others can offer advice or
experiences but they can’t give you the right answers.

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org