Workflow: user => stories/features => spec => code => user

Testing RSpec
1

Hi,

I am still trying to learn how to effectively use BDD. I would like to
know if there is a typical BDD workflow or if it is really just a
question of personal preference.

So far I see the following steps being fairly common:

  1. talk with user to establish a few stories and features
  2. write plaintext stories or cucumber features (with the user?)
  3. write specs for whatever step needs to be wnitten
  4. code until specs pass
  5. write story/feature steps
  6. repeat steps 3-5 until the story/feature passes
  7. show the user to confirm that it works the way the user want (and
    go back to step 2 if it doesn’t)
  8. go back to step 1 for new stories/features

Is that how you do things? Should I do it this way? How flexible
should this process be? For example, if the user wants a tiny change,
should I always be so disciplined as to update the story first, then
the specs, and then code?

Thanks!

2

On 19 Sep 2008, at 02:00, DyingToLearn wrote:

  1. write specs for whatever step needs to be wnitten
  2. code until specs pass
  3. write story/feature steps
  4. repeat steps 3-5 until the story/feature passes
  5. show the user to confirm that it works the way the user want (and
    go back to step 2 if it doesn’t)
  6. go back to step 1 for new stories/features

This seems to be pretty much the workflow that’s evolving for us,
though I tend to write the step implementations before I start coding
the views, controller, models. (i.e. 5 before 3)/

It’s the ‘outside-in’ model of development that Dan N. talks about

  • driving out all your changes to the code from a real user goal.

Is that how you do things? Should I do it this way? How flexible
should this process be? For example, if the user wants a tiny change,
should I always be so disciplined as to update the story first, then
the specs, and then code?

IMO, you have to be pragmatic - maybe you can just change the spec of
a controller to listen for another querystring parameter value and do
something different - I don’t think that necessarily needs the full
ceremony of another feature scenario.

Thanks!

rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

cheers,
Matt

http://blog.mattwynne.net

In case you wondered: The opinions expressed in this email are my own
and do not necessarily reflect the views of any former, current or
future employers of mine.

3

On 19.9.2008, at 10.58, Matt W. wrote:

This seems to be pretty much the workflow that’s evolving for us,
though I tend to write the step implementations before I start
coding the views, controller, models. (i.e. 5 before 3)/

Ditto, and also, don’t write all the specs at a time. My plan for 3-5
is something like this:

  1. Write the first step of the feature in question
  2. Write the view spec to satisfy the step code
  3. Write the view functionality to make 4 pass
  4. Write the controller spec to satisfy the needs of 4
  5. Write the code to make 6 pass
  6. Write the model spec to satisfy the needs of 6
  7. Write the code to make 8 pass
    At this point the step should pass, so go back to 3 and repeat with
    the next step.

Note that I left out the refactoring part of the TDD cycle here. It
generally happens between every layer after the specs pass.

//jarkko

–
Jarkko L.

http://www.railsecommerce.com
http://odesign.fi

4

sometimes i do
story => code => spec => (re)code => story step => (re)code => spec
=> (re)code
or whatever, but hey, thats just me…
:slight_smile:

5

On Sep 19, 2008, at 4:09 AM, Jarkko L. wrote:

question of personal preference.
go back to step 2 if it doesn’t)

  1. Write the view spec to satisfy the step code
  2. Write the view functionality to make 4 pass
  3. Write the controller spec to satisfy the needs of 4
  4. Write the code to make 6 pass
  5. Write the model spec to satisfy the needs of 6
  6. Write the code to make 8 pass
    At this point the step should pass, so go back to 3 and repeat with
    the next step.

Note that I left out the refactoring part of the TDD cycle here. It
generally happens between every layer after the specs pass.

As far as I can remember, this is how Pat introduced described his
cycle in the screencast he posted on the story runner when it first
came out. I’d be curious to see if (and how) he has changed his
workflow since then.

Scott

6

hi there,
you might wanna be insterest in this talk on Stories DD by webrat
maintainer
at GoRuCo 2008 http://goruco2008.confreaks.com/01_helmkamp.html

there he hightlights the workflow like this:

  1. Write scenario (yellow color)
  2. Write steps matchers (red color)
  3. Write code (green color)
  4. refactor (even greener ;-))

and according to him you loop between 2 and 3, and you can even be a
little
relaxed between 2 and 3 ( make a little of 3 to know what your page will
look like before 2)

check it out, its great
joaquin

2008/9/19 Jonathan L. [email protected]

7

Scott T. wrote:

As far as I can remember, this is how Pat introduced described his
cycle in the screencast he posted on the story runner when it first
came out.

I’ve been caught in plagiarism!
I actually wrote this message while I was watching that screencast.

Thanks to everyone for your comments (and the link to that video).

Paul