rspec users - Sep 2008 - workflow: user => stories/features => spec => code => user

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!

On 19 Sep 2008, at 02:00, DyingToLearn wrote:
> 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
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
North 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
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
cheers,
Matt
----
http://blog.mattwynne.net
http://songkick.com

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.

On 19.9.2008, at 10.58, Matt Wynne wrote:
> On 19 Sep 2008, at 02:00, DyingToLearn wrote:
>
>> 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
>
> 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:

3. Write the first step of the feature in question
4. Write the view spec to satisfy the step code
5. Write the view functionality to make 4 pass
6. Write the controller spec to satisfy the needs of 4
7. Write the code to make 6 pass
8. Write the model spec to satisfy the needs of 6
9. 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 Laine
http://jlaine.net
http://dotherightthing.com
http://www.railsecommerce.com
http://odesign.fi

On Sep 19, 2008, at 4:09 AM, Jarkko Laine wrote:
>
> On 19.9.2008, at 10.58, Matt Wynne wrote:
>
>> On 19 Sep 2008, at 02:00, DyingToLearn wrote:
>>
>>> 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
>>
>> 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:
>
> 3. Write the first step of the feature in question
> 4. Write the view spec to satisfy the step code
> 5. Write the view functionality to make 4 pass
> 6. Write the controller spec to satisfy the needs of 4
> 7. Write the code to make 6 pass
> 8. Write the model spec to satisfy the needs of 6
> 9. 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

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

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 Linowes <jonathan at parkerhill.com>
> sometimes i do
> story => code => spec => (re)code => story step => (re)code
=> spec =>
> (re)code
> or whatever, but hey, thats just me...
> :)
>
>
>
> _______________________________________________
> 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/20080919/79405dcf/attachment.html>

Scott Taylor 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