I am new to BDD and have been doing some reading and playing with rSpec. I am a little confused. I am not sure what the best practice for using stories and specs. Should I be writing stories first, then specs that would fulfill those stories, and then write the implementation code to have everything pass? At first that seems a little redundant. I understand that the stories let you write the behavior in plane English, which I can see it being useful when dealing with non technical users. But if I am developing an internal app I am struggling with whether I should develop the stories first and then move on to the specs. Opinions? Experiences? Thanks, Victor
My workflow is the following: Stories->Spec Views->Spec Controllers-Spec Models I''ll write a few stories of what I think should it happen. Then I''ll write my specs of what should show (and also do some static html page mockups) Then I''ll spec my controllers and models I''ll go back to my stories to see if they need adjusting because my perceptive of how the app changed Then I run my stories and make them pass. Then I write a few stories and repeat. I constantly step move back and forth. I think Stories and BDD greatly assists you to shape your idea. Write stories for what you can think of and then move on to specing. You don''t need complete stories you can also go back and fill them in later. On Feb 18, 2008 2:57 AM, Victor Asteinza <vic at civrot.org> wrote:> I am new to BDD and have been doing some reading and playing with > rSpec. I am a little confused. I am not sure what the best practice > for using stories and specs. Should I be writing stories first, then > specs that would fulfill those stories, and then write the > implementation code to have everything pass? At first that seems a > little redundant. > > I understand that the stories let you write the behavior in plane > English, which I can see it being useful when dealing with non > technical users. But if I am developing an internal app I am > struggling with whether I should develop the stories first and then > move on to the specs. > > Opinions? Experiences? > > Thanks, > Victor > _______________________________________________ > 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/20080218/2fd08018/attachment.html
Isn''t there redundancy between what is in your stories and your specs? Or are your stories at a higher level and the specs are at a lower level? That would make more sense to me. There would be some cross over. but the specs expand on what is in the stories....> Message: 3 > Date: Mon, 18 Feb 2008 11:21:47 -0500 > From: "Andrew WC Brown" <omen.king at gmail.com> > Subject: Re: [rspec-users] Specs versus Stories > To: rspec-users <rspec-users at rubyforge.org> > Message-ID: > <ef1d468f0802180821v42276d2fw96b0041a497a2664 at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > My workflow is the following: > Stories->Spec Views->Spec Controllers-Spec Models > > I''ll write a few stories of what I think should it happen. > Then I''ll write my specs of what should show (and also do some > static html > page mockups) > Then I''ll spec my controllers and models > I''ll go back to my stories to see if they need adjusting because my > perceptive of how the app changed > Then I run my stories and make them pass. > > Then I write a few stories and repeat. > > I constantly step move back and forth. > I think Stories and BDD greatly assists you to shape your idea. > Write stories for what you can think of and then move on to specing. > You don''t need complete stories you can also go back and fill them > in later. > > On Feb 18, 2008 2:57 AM, Victor Asteinza <vic at civrot.org> wrote: > >> I am new to BDD and have been doing some reading and playing with >> rSpec. I am a little confused. I am not sure what the best practice >> for using stories and specs. Should I be writing stories first, then >> specs that would fulfill those stories, and then write the >> implementation code to have everything pass? At first that seems a >> little redundant. >> >> I understand that the stories let you write the behavior in plane >> English, which I can see it being useful when dealing with non >> technical users. But if I am developing an internal app I am >> struggling with whether I should develop the stories first and then >> move on to the specs. >> >> Opinions? Experiences? >> >> Thanks, >> Victor >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >>
On Feb 18, 2008 6:38 PM, Victor Asteinza <vic at civrot.org> wrote:> Isn''t there redundancy between what is in your stories and your specs? > Or are your stories at a higher level and the specs are at a lower > level? That would make more sense to me. There would be some cross > over. but the specs expand on what is in the stories....While either tool can technically support either mode of thinking: Stories are aimed at describing the behaviour of your applications. Specs are aimed at describing the behaviour of the objects in your applications. You are correct that there will likely be some cross over, but keep in mind that there are different audiences and different processes. The steps in stories (the descriptive text, not the implementation of the steps) are typically written in entirety before setting out to develop a body of work. Stories should be run before a commit, or as part of a CI build, but are not always run between every step. The examples in specs, on the other hand, typically come into existence in a very granular red-green-refactor cycle, and should be run between every step. HTH, David> > > Message: 3 > > Date: Mon, 18 Feb 2008 11:21:47 -0500 > > From: "Andrew WC Brown" <omen.king at gmail.com> > > Subject: Re: [rspec-users] Specs versus Stories > > To: rspec-users <rspec-users at rubyforge.org> > > Message-ID: > > <ef1d468f0802180821v42276d2fw96b0041a497a2664 at mail.gmail.com> > > Content-Type: text/plain; charset="iso-8859-1" > > > > > My workflow is the following: > > Stories->Spec Views->Spec Controllers-Spec Models > > > > I''ll write a few stories of what I think should it happen. > > Then I''ll write my specs of what should show (and also do some > > static html > > page mockups) > > Then I''ll spec my controllers and models > > I''ll go back to my stories to see if they need adjusting because my > > perceptive of how the app changed > > Then I run my stories and make them pass. > > > > Then I write a few stories and repeat. > > > > I constantly step move back and forth. > > I think Stories and BDD greatly assists you to shape your idea. > > Write stories for what you can think of and then move on to specing. > > You don''t need complete stories you can also go back and fill them > > in later. > > > > On Feb 18, 2008 2:57 AM, Victor Asteinza <vic at civrot.org> wrote: > > > >> I am new to BDD and have been doing some reading and playing with > >> rSpec. I am a little confused. I am not sure what the best practice > >> for using stories and specs. Should I be writing stories first, then > >> specs that would fulfill those stories, and then write the > >> implementation code to have everything pass? At first that seems a > >> little redundant. > >> > >> I understand that the stories let you write the behavior in plane > >> English, which I can see it being useful when dealing with non > >> technical users. But if I am developing an internal app I am > >> struggling with whether I should develop the stories first and then > >> move on to the specs. > >> > >> Opinions? Experiences? > >> > >> Thanks, > >> Victor > >> _______________________________________________ > >> rspec-users mailing list > >> rspec-users at rubyforge.org > >> http://rubyforge.org/mailman/listinfo/rspec-users > >> > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
Andrew, By testing your views before the controllers and models, aren''t you wasting time on adjusting tests as you make changes to the views? I see many people postpone the testing of views to the very late stage of development, so that they don''t get distracted. -- Posted via http://www.ruby-forum.com/.
On 19.2.2008, at 12.32, Fernando Perez wrote:> Andrew, > > By testing your views before the controllers and models, aren''t you > wasting time on adjusting tests as you make changes to the views? > > I see many people postpone the testing of views to the very late stage > of development, so that they don''t get distracted.One of the founding principles of BDD is the concept of "outside in". In Rails that naturally means the process Andrew described. By starting from what your views need, you have a better understanding of what you need from the controller action and related models, so you have a good foundation from where you start speccing them when you drill down towards the core. That also follows one of the 37signals'' mantras that is worth repeating: "the interface is the application". If changing some small things (like a <p> to <div>) in the views breaks your specs, you''re probably speccing wrong things. I always try to spec for logical things, not the actual tags, for example. That is not always an option, of course. //jarkko -- Jarkko Laine http://jlaine.net http://dotherightthing.com http://www.railsecommerce.com http://odesign.fi -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available Url : http://rubyforge.org/pipermail/rspec-users/attachments/20080219/774ab30e/attachment.bin
I try to thing of the audience for the work, and it keeps me sane. Stories are to make sure you''re holding up your contract with the client or user. They are high level, and don''t deal with any implementation details that can be abstracted away. You might relate them to acceptance tests, because when you pass stories, you''re passing all the acceptance criteria. You also might compare them integration tests, because they should ensure everything behind the UI (or API) works correctly. It''s reasonable to mock external services, but I try to have these be as real as possible. If you and your user disagree about how something works, you make the change in the story. Then you change the specs and code as needed. Specs are to make sure you''re holding up your contract with the code and its developers. With so little static checking in ruby, specs are your type checking, exception checking (ala java), the preconditions, postconditions, and invariants (ala DbC), published interface, performance profiler, and possibly even internal documentation. These make sure you know the right way to interact with the code. And of course you should specify the code before you implement it, red-green style. If you and a developer disagree about how something works, you make the change in the specs. Then you change the code as needed. Clear as mud? On 02008:02:18, at 5:44CST, David Chelimsky wrote:> On Feb 18, 2008 6:38 PM, Victor Asteinza <vic at civrot.org> wrote: >> Isn''t there redundancy between what is in your stories and your >> specs? >> Or are your stories at a higher level and the specs are at a lower >> level? That would make more sense to me. There would be some cross >> over. but the specs expand on what is in the stories.... > > While either tool can technically support either mode of thinking: > > Stories are aimed at describing the behaviour of your applications. > Specs are aimed at describing the behaviour of the objects in your > applications. > > You are correct that there will likely be some cross over, but keep in > mind that there are different audiences and different processes. > > The steps in stories (the descriptive text, not the implementation of > the steps) are typically written in entirety before setting out to > develop a body of work. Stories should be run before a commit, or as > part of a CI build, but are not always run between every step. > > The examples in specs, on the other hand, typically come into > existence in a very granular red-green-refactor cycle, and should be > run between every step. > > HTH, > David > > >> >>> Message: 3 >>> Date: Mon, 18 Feb 2008 11:21:47 -0500 >>> From: "Andrew WC Brown" <omen.king at gmail.com> >>> Subject: Re: [rspec-users] Specs versus Stories >>> To: rspec-users <rspec-users at rubyforge.org> >>> Message-ID: >>> <ef1d468f0802180821v42276d2fw96b0041a497a2664 at mail.gmail.com> >>> Content-Type: text/plain; charset="iso-8859-1" >> >>> >>> My workflow is the following: >>> Stories->Spec Views->Spec Controllers-Spec Models >>> >>> I''ll write a few stories of what I think should it happen. >>> Then I''ll write my specs of what should show (and also do some >>> static html >>> page mockups) >>> Then I''ll spec my controllers and models >>> I''ll go back to my stories to see if they need adjusting because my >>> perceptive of how the app changed >>> Then I run my stories and make them pass. >>> >>> Then I write a few stories and repeat. >>> >>> I constantly step move back and forth. >>> I think Stories and BDD greatly assists you to shape your idea. >>> Write stories for what you can think of and then move on to specing. >>> You don''t need complete stories you can also go back and fill them >>> in later. >>> >>> On Feb 18, 2008 2:57 AM, Victor Asteinza <vic at civrot.org> wrote: >>> >>>> I am new to BDD and have been doing some reading and playing with >>>> rSpec. I am a little confused. I am not sure what the best >>>> practice >>>> for using stories and specs. Should I be writing stories first, >>>> then >>>> specs that would fulfill those stories, and then write the >>>> implementation code to have everything pass? At first that seems a >>>> little redundant. >>>> >>>> I understand that the stories let you write the behavior in plane >>>> English, which I can see it being useful when dealing with non >>>> technical users. But if I am developing an internal app I am >>>> struggling with whether I should develop the stories first and then >>>> move on to the specs. >>>> >>>> Opinions? Experiences? >>>> >>>> Thanks, >>>> Victor >>>> _______________________________________________ >>>> rspec-users mailing list >>>> rspec-users at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/rspec-users >>>> >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-usershttp:// Joseph Holsten .com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20080221/1cf6e73c/attachment.html
There are automated & manual tests. Automated customer facing & Automated developer tests. Both customer facing and developer tests can have a unit, functional, and integration scope. That being said, you can have effective high level developer Specs. Stories are great for facilitation communication, especially with nondevelopers. It may also be useful in organizing the developer''s thoughts too. There may also be other benefits that I''m missing here. However, there is an additional investment needed to build up your Story dsl, than would be expended in using high level Specs. Does the value of having Stories outweigh the costs in your situation? I think the best practice is what makes the most sense to you. On Thu, Feb 21, 2008 at 11:02 AM, Joseph Anthony Pasquale Holsten <joseph at josephholsten.com> wrote:> I try to thing of the audience for the work, and it keeps me sane. > > Stories are to make sure you''re holding up your contract with the client or > user. They are high level, and don''t deal with any implementation details > that can be abstracted away. You might relate them to acceptance tests, > because when you pass stories, you''re passing all the acceptance criteria. > You also might compare them integration tests, because they should ensure > everything behind the UI (or API) works correctly. It''s reasonable to mock > external services, but I try to have these be as real as possible. > > If you and your user disagree about how something works, you make the change > in the story. Then you change the specs and code as needed. > > Specs are to make sure you''re holding up your contract with the code and its > developers. With so little static checking in ruby, specs are your type > checking, exception checking (ala java), the preconditions, postconditions, > and invariants (ala DbC), published interface, performance profiler, and > possibly even internal documentation. These make sure you know the right way > to interact with the code. And of course you should specify the code before > you implement it, red-green style. > > If you and a developer disagree about how something works, you make the > change in the specs. Then you change the code as needed. > > Clear as mud? > > > > On 02008:02:18, at 5:44CST, David Chelimsky wrote: > > On Feb 18, 2008 6:38 PM, Victor Asteinza <vic at civrot.org> wrote: > Isn''t there redundancy between what is in your stories and your specs? > Or are your stories at a higher level and the specs are at a lower > level? That would make more sense to me. There would be some cross > over. but the specs expand on what is in the stories.... > > While either tool can technically support either mode of thinking: > > Stories are aimed at describing the behaviour of your applications. > Specs are aimed at describing the behaviour of the objects in your > applications. > > You are correct that there will likely be some cross over, but keep in > mind that there are different audiences and different processes. > > The steps in stories (the descriptive text, not the implementation of > the steps) are typically written in entirety before setting out to > develop a body of work. Stories should be run before a commit, or as > part of a CI build, but are not always run between every step. > > The examples in specs, on the other hand, typically come into > existence in a very granular red-green-refactor cycle, and should be > run between every step. > > HTH, > David > > > > > > Message: 3 > Date: Mon, 18 Feb 2008 11:21:47 -0500 > From: "Andrew WC Brown" <omen.king at gmail.com> > Subject: Re: [rspec-users] Specs versus Stories > To: rspec-users <rspec-users at rubyforge.org> > Message-ID: > <ef1d468f0802180821v42276d2fw96b0041a497a2664 at mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > > > My workflow is the following: > Stories->Spec Views->Spec Controllers-Spec Models > > I''ll write a few stories of what I think should it happen. > Then I''ll write my specs of what should show (and also do some > static html > page mockups) > Then I''ll spec my controllers and models > I''ll go back to my stories to see if they need adjusting because my > perceptive of how the app changed > Then I run my stories and make them pass. > > Then I write a few stories and repeat. > > I constantly step move back and forth. > I think Stories and BDD greatly assists you to shape your idea. > Write stories for what you can think of and then move on to specing. > You don''t need complete stories you can also go back and fill them > in later. > > On Feb 18, 2008 2:57 AM, Victor Asteinza <vic at civrot.org> wrote: > > > I am new to BDD and have been doing some reading and playing with > rSpec. I am a little confused. I am not sure what the best practice > for using stories and specs. Should I be writing stories first, then > specs that would fulfill those stories, and then write the > implementation code to have everything pass? At first that seems a > little redundant. > > I understand that the stories let you write the behavior in plane > English, which I can see it being useful when dealing with non > technical users. But if I am developing an internal app I am > struggling with whether I should develop the stories first and then > move on to the specs. > > Opinions? Experiences? > > Thanks, > Victor > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > > http:// Joseph Holsten .com > > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
Brian Takita wrote:> There are automated & manual tests. > Automated customer facing & Automated developer tests. > Both customer facing and developer tests can have a unit, functional, > and integration scope. > > That being said, you can have effective high level developer Specs.They certainly can, but I wonder who is. Does anyone have experiences with this specification (opposed to story-telling) at a high level they would share?> Stories are great for facilitation communication, especially with > nondevelopers. It may also be useful in organizing the developer''s > thoughts too. There may also be other benefits that I''m missing here.So how about that opposite, is anyone using story-telling internally but not getting them from (or even sharing them with) clients? How''s that working?> However, there is an additional investment needed to build up your > Story dsl, than would be expended in using high level Specs. > Does the value of having Stories outweigh the costs in your situation? > I think the best practice is what makes the most sense to you.That''s how I always defined best! http:// Joseph Holsten .com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20080223/35211c29/attachment.html