Disclaimer: The following are observations by a relatively new user (couple of weeks) of RSpec and not intended as RSpec trollbait. Also, forgive me if similar topics have been discussed elsewhere on the mailing list. I at least did the due diligence of a quick search. That said... I''ve been positively thrilled with RSpec for use outside of Rails. It has been in my attempts to use it within Rails that I have begun to question whether and how it can buy me much more than Test::Unit. I recently began using RSpec to drive the design, in BDD fashion, of a Rails app. Believing that behavior is best measured from the user''s experience, I started by writing a View spec. I considered this a top-down approach. Were I still using Test::Unit, I likely would have started in the same place that I usually do out of habit: the Model. However, the more googling that I''ve done, the more that I noticed that most RSpec articles, where they addressed Rails, were primarily focused on the Model. I began to wonder, "are people using RSpec much like people were using Test::Unit?" I''ve seen that some people eschew View Specs. However, in lieu of that, how does one spec the interface that should, in theory, drive the design of the application? Ultimately, I''m left with similar perspective to Jordan''s: View specs will be brittle. They''ll span multiple Behaviors as there will be at least one per action -- leading me to wonder if BDD, or at least RSpec, is necessarily the best way to try to spec the View. However, Controllers and Models seem as though they would work reasonably well. Can anyone recommend some approaches for tackling BDD starting from the View down? Thanks, Evan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070912/cef3e0b7/attachment.html
On 9/12/2007 3:55 PM, Evan David Light wrote:> Disclaimer: The following are observations by a relatively new user > (couple of weeks) of RSpec and not intended as RSpec trollbait. Also, > forgive me if similar topics have been discussed elsewhere on the > mailing list. I at least did the due diligence of a quick search. > > That said... > > I''ve been positively thrilled with RSpec for use outside of Rails. It > has been in my attempts to use it within Rails that I have begun to > question whether and how it can buy me much more than Test::Unit. > > I recently began using RSpec to drive the design, in BDD fashion, of a > Rails app. Believing that behavior is best measured from the user''s > experience, I started by writing a View spec. I considered this a > top-down approach. Were I still using Test::Unit, I likely would have > started in the same place that I usually do out of habit: the Model. > > However, the more googling that I''ve done, the more that I noticed that > most RSpec articles, where they addressed Rails, were primarily focused > on the Model. I began to wonder, "are people using RSpec much like > people were using Test::Unit?" I''ve seen that some people eschew View > Specs <http://tuples.us/2007/08/17/my-life-with-bdd-and-rspec/>. > However, in lieu of that, how does one spec the interface that should, > in theory, drive the design of the application? > > Ultimately, I''m left with similar perspective to Jordan''s: View specs > will be brittle. They''ll span multiple Behaviors as there will be at > least one per action -- leading me to wonder if BDD, or at least RSpec, > is necessarily the best way to try to spec the View. However, > Controllers and Models seem as though they would work reasonably well. > > Can anyone recommend some approaches for tackling BDD starting from the > View down?I think it''s really hard right now for exactly the reasons you mention. I think Story Runner will make it much, much easier. Jay
On 9/12/07, Evan David Light <evan at tiggerpalace.com> wrote:> Disclaimer: The following are observations by a relatively new user (couple > of weeks) of RSpec and not intended as RSpec trollbait. Also, forgive me if > similar topics have been discussed elsewhere on the mailing list. I at > least did the due diligence of a quick search. > > That said... > > I''ve been positively thrilled with RSpec for use outside of Rails. It has > been in my attempts to use it within Rails that I have begun to question > whether and how it can buy me much more than Test::Unit. > > I recently began using RSpec to drive the design, in BDD fashion, of a > Rails app. Believing that behavior is best measured from the user''s > experience, I started by writing a View spec. I considered this a top-down > approach. Were I still using Test::Unit, I likely would have started in the > same place that I usually do out of habit: the Model. > > However, the more googling that I''ve done, the more that I noticed that > most RSpec articles, where they addressed Rails, were primarily focused on > the Model. I began to wonder, "are people using RSpec much like people were > using Test::Unit?" I''ve seen that some people eschew View Specs. However, > in lieu of that, how does one spec the interface that should, in theory, > drive the design of the application? > > Ultimately, I''m left with similar perspective to Jordan''s: View specs will > be brittle. They''ll span multiple Behaviors as there will be at least one > per action -- leading me to wonder if BDD, or at least RSpec, is necessarily > the best way to try to spec the View. However, Controllers and Models seem > as though they would work reasonably well.I like to start w/ integration tests before anything exists at all. You can do that w/ Rails'' Integration Tests or Story Runner (if you''re using RSpec''s trunk). Next, I hit a view. View specs DO get brittle fast, and such warnings are useful advice, however that does not mean you shouldn''t do them. If you change a view template and a loose an important form element then the form doesn''t work. That''s broken software, brittle specs or not. If you don''t want broken software, then spec the views - but ONLY the stuff that actually has business value. Once the view is sufficiently spec''d and the specs are passing, I know what the controller needs to supply, so I start spec''ing the controller. And on down to models. I think the reason there''s so much posted about spec''ing models is because there''s so much controversy over "the right way" to do it. The sad fact is that spec''ing models sucks if you''re trying to keep "pure BDD" (can someone explain what that means?) because it means you end up either testing stuff that''s already tested by Rails (a TDD no-no) or you''re hitting the database (another TDD no-no). On the flip side, if you''re trying to get things to go fast and keep things isolated, then you end up violating BDD sensibilities, which also sucks. The thing is that most of the debate has been about aesthetics and hypotheticals. We''ll learn a lot more over time as people who espouse different approaches write about how the different approaches effect the long term. The whole reason we started the BDD discussion was because ppl were trying TDD and not getting stuff done because they kept over-engineering themselves down rat holes! In the end, that''s the most important measure: Does your approach help you get stuff done? If an approach isn''t helping you getting stuff done, then it''s just BDC: Bullshit Driven Catastrophe. That''s not to say that the philosophy isn''t important. I, personally, love talking about philosophy. It helps me to understand why I gravitate towards the things I do. But keep in mind that philosophy/theory is usually there to try to explain natural phenomena. Design patterns just were - they weren''t created. They were then recognized, documented, and now instead of solving problems with them people create problems with them by thinking about using them before there''s a problem to solve. They were never there to solve problems in advance. They were there to solve problems you were actually having. Same w/ approaches to testing and developing software. Agile isn''t all that agile if we''re all finding "best practices" and applying them like a bunch of blind followers of some religion. "We have come to value individuals and interactions over processes and tools," yet we''re always becoming slave to the next tool rather than becoming its master and sticking it in our tool belt. Wow - that was an unexpected rant. Thanks for prompting it!!! Guess the whole religion thing has been on my mind for a while. Summing up - the series of steps I described above is what I *usually* do because I know it works for me and the way I work. But I don''t do that 100% of the time, and I certainly don''t feel bad when I break that pattern. It''s just a great tool to have lying around. Cheers, David> > Can anyone recommend some approaches for tackling BDD starting from the > View down? > > Thanks, > Evan > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
Awesome! That''s a whole lot more of a response than I had anticipated. Thanks! On Sep 12, 2007, at 6:15 PM, David Chelimsky wrote:> On 9/12/07, Evan David Light <evan at tiggerpalace.com> wrote: > I like to start w/ integration tests before anything exists at all. > You can do that w/ Rails'' Integration Tests or Story Runner (if you''re > using RSpec''s trunk). >Story Runner is a new one for me. I''ll have to look it up. Thanks! (Halfway through writing this, I realized, courtesy of Google, that it''s a recently integrated piece of functionality into RSpec-on- Rails. I found this example of yours captured here. ) I see why this could be a good way to start coding. This is exactly what I naturally wanted to do with RSpec but couldn''t because RSpec seems oriented toward a lower-level set of issues. I''ll have to start playing with the trunk now. This looks nifty.> If you don''t want broken software, then spec the views - but ONLY > the stuff that actually has business value. >Seems like sound common sense. I caught myself earlier today writing a spec for a non-functional portion of my view, chided myself for it, ripped out the spec, and then continued.> Once the view is sufficiently spec''d and the specs are passing, I know > what the controller needs to supply, so I start spec''ing the > controller. And on down to models.Good to realize that I''m not thinking that far off the mainstream here.> That''s not to say that the philosophy isn''t important. I, personally, > love talking about philosophy. It helps me to understand why I > gravitate towards the things I do.Ultimately, this is what I was looking for: not so much "what to do" but the "tao" of it. Starting with the user in mind, from a view level, made some sense but too minutiae driven. I like to dabble with new approaches but always asking "why?" along the way. While a lot of what I have been doing with RSpec could be accomplished with Test::Unit, I''m finding that I prefer the RSpec approach somewhat more.> Same w/ approaches to testing and developing software. Agile isn''t all > that agile if we''re all finding "best practices" and applying them > like a bunch of blind followers of some religion.Or if we spend so much time on "best practices" that we''re not actually accomplishing anything? Welcome to the government. ;-)> "We have come to > value individuals and interactions over processes and tools," yet > we''re always becoming slave to the next tool rather than becoming its > master and sticking it in our tool belt.<wisecrack> You mean that instead of being Java Juju Zombies that we''re becoming Ruby Robots? </wisecrack>> Summing up - the series of steps I described above is what I *usually* > do because I know it works for me and the way I work. But I don''t do > that 100% of the time, and I certainly don''t feel bad when I break > that pattern. It''s just a great tool to have lying around. >And, of course, what works for one may not work for all. However, with regard to Rails apps, I''m still finding my way. That said, I know that I would prefer a TDD/BDD approach to writing it, hand testing it, seeing it mostly work, fix something (and perhaps breaking something else!), rinsing and repeating. Thanks for the brain dump! Evan IMs (all): sleight42 http://evan.tiggerpalace.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070912/b75e7fb6/attachment-0001.html
On 9/12/07, Evan David Light <evan at tiggerpalace.com> wrote:> Awesome! That''s a whole lot more of a response than I had anticipated.Me too.> Thanks! > > On Sep 12, 2007, at 6:15 PM, David Chelimsky wrote: > > On 9/12/07, Evan David Light <evan at tiggerpalace.com> wrote: > I like to start w/ integration tests before anything exists at all. > You can do that w/ Rails'' Integration Tests or Story Runner (if you''re > using RSpec''s trunk). > > > Story Runner is a new one for me. I''ll have to look it up. Thanks! > > (Halfway through writing this, I realized, courtesy of Google, that it''s a > recently integrated piece of functionality into RSpec-on-Rails. I found > this example of yours captured here. )Not specific to Rails at all. Just happens to support Rails.> > I see why this could be a good way to start coding. This is exactly what I > naturally wanted to do with RSpec but couldn''t because RSpec seems oriented > toward a lower-level set of issues. I''ll have to start playing with the > trunk now. This looks nifty. > > > If you don''t want broken software, then spec the views - but ONLY > the stuff that actually has business value. > > Seems like sound common sense. I caught myself earlier today writing a spec > for a non-functional portion of my view, chided myself for it, ripped out > the spec, and then continued.Careful here. Business value is not always measured in terms of things "functional". Sometimes it''s the company logo showing up in the right place on the page after spending thousands of marketing dollars figuring out where that spot is.> Once the view is sufficiently spec''d and the specs are passing, I know > what the controller needs to supply, so I start spec''ing the > controller. And on down to models. > > Good to realize that I''m not thinking that far off the mainstream here.Eeeek. You''re not thinking far off from ME. That in no way makes it main stream.> That''s not to say that the philosophy isn''t important. I, personally, > love talking about philosophy. It helps me to understand why I > gravitate towards the things I do. > > Ultimately, this is what I was looking for: not so much "what to do" but the > "tao" of it. Starting with the user in mind, from a view level, made some > sense but too minutiae driven. I like to dabble with new approaches but > always asking "why?" along the way. While a lot of what I have been doing > with RSpec could be accomplished with Test::Unit, I''m finding that I prefer > the RSpec approach somewhat more. > > > Same w/ approaches to testing and developing software. Agile isn''t all > that agile if we''re all finding "best practices" and applying them > like a bunch of blind followers of some religion. > > Or if we spend so much time on "best practices" that we''re not actually > accomplishing anything? Welcome to the government. ;-) > > "We have come to > value individuals and interactions over processes and tools," yet > we''re always becoming slave to the next tool rather than becoming its > master and sticking it in our tool belt. > > <wisecrack> You mean that instead of being Java Juju Zombies that we''re > becoming Ruby Robots? </wisecrack> > > Summing up - the series of steps I described above is what I *usually* > do because I know it works for me and the way I work. But I don''t do > that 100% of the time, and I certainly don''t feel bad when I break > that pattern. It''s just a great tool to have lying around. > > > And, of course, what works for one may not work for all. However, with > regard to Rails apps, I''m still finding my way. That said, I know that I > would prefer a TDD/BDD approach to writing it, hand testing it, seeing it > mostly work, fix something (and perhaps breaking something else!), rinsing > and repeating. > > Thanks for the brain dump!Thanks for cleaning it up!!! Cheers, David
On 9/12/07, David Chelimsky <dchelimsky at gmail.com> wrote:> > I like to start w/ integration tests before anything exists at all. > You can do that w/ Rails'' Integration Tests or Story Runner (if you''re > using RSpec''s trunk). > > Next, I hit a view.... Despite the time involved, I''d love to see a written tutorial or screencast that walks this whole gamut in order if someone ever has time to do one. - Geoffrey -- Geoffrey Wiseman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070912/5cff2d61/attachment.html
On 9/12/07, Geoffrey Wiseman <geoffrey.wiseman at gmail.com> wrote:> On 9/12/07, David Chelimsky <dchelimsky at gmail.com> wrote: > > I like to start w/ integration tests before anything exists at all. > > You can do that w/ Rails'' Integration Tests or Story Runner (if you''re > > using RSpec''s trunk). > > > > Next, I hit a view. > > ... > > Despite the time involved, I''d love to see a written tutorial or screencast > that walks this whole gamut in order if someone ever has time to do one.Me too!> - Geoffrey > -- > Geoffrey Wiseman > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Sep 12, 2007, at 7:35 PM, David Chelimsky wrote:>> Story Runner is a new one for me. I''ll have to look it up. Thanks! >> >> (Halfway through writing this, I realized, courtesy of Google, >> that it''s a >> recently integrated piece of functionality into RSpec-on-Rails. I >> found >> this example of yours captured here. ) > > Not specific to Rails at all. Just happens to support Rails. >Gotcha. Tomorrow I''ll be checking out from trunk. Although it behooves me to ask if the RSpec (and integration tests/story runner) in trunk all pass.>> Seems like sound common sense. I caught myself earlier today >> writing a spec >> for a non-functional portion of my view, chided myself for it, >> ripped out >> the spec, and then continued. > > Careful here. Business value is not always measured in terms of things > "functional". Sometimes it''s the company logo showing up in the right > place on the page after spending thousands of marketing dollars > figuring out where that spot is. >Granted. Anything that is a customer requirement should be captured at some level. That said, the Rails app that I''m writing at the moment is a tool to support an R&D effort so none of that sort of thing there.>> Good to realize that I''m not thinking that far off the mainstream >> here. > > Eeeek. You''re not thinking far off from ME. That in no way makes it > main stream. >Hehe. Ok, I''m thinking like a guy who has prolific dialogues about how to build better software. I could do worse. ;-) Evan
On 9/12/07, Evan David Light <evan at tiggerpalace.com> wrote:> > On Sep 12, 2007, at 7:35 PM, David Chelimsky wrote: > > >> Story Runner is a new one for me. I''ll have to look it up. Thanks! > >> > >> (Halfway through writing this, I realized, courtesy of Google, > >> that it''s a > >> recently integrated piece of functionality into RSpec-on-Rails. I > >> found > >> this example of yours captured here. ) > > > > Not specific to Rails at all. Just happens to support Rails. > > > > Gotcha. Tomorrow I''ll be checking out from trunk. Although it > behooves me to ask if the RSpec (and integration tests/story runner) > in trunk all pass.Pass? Pass? Puh-lease!!!!!! We don''t commit to trunk w/ out 100% coverage in core (not there yet for the rails plugin) and all rails plugin specs passing against 1.2.1, .1.2.2 and .1.2.3. We also run them against edge rails, but we just use that to keep issues on the radar - passing against edge is not a pre-condition for committing.> >> Seems like sound common sense. I caught myself earlier today > >> writing a spec > >> for a non-functional portion of my view, chided myself for it, > >> ripped out > >> the spec, and then continued. > > > > Careful here. Business value is not always measured in terms of things > > "functional". Sometimes it''s the company logo showing up in the right > > place on the page after spending thousands of marketing dollars > > figuring out where that spot is. > > > > Granted. Anything that is a customer requirement should be captured > at some level. That said, the Rails app that I''m writing at the > moment is a tool to support an R&D effort so none of that sort of > thing there. > > >> Good to realize that I''m not thinking that far off the mainstream > >> here. > > > > Eeeek. You''re not thinking far off from ME. That in no way makes it > > main stream. > > > > Hehe. Ok, I''m thinking like a guy who has prolific dialogues about > how to build better software. I could do worse. ;-)Well - my earlier post was more like a monologue than dialog, but thanks! Cheers, David> > Evan > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On 9/12/07, Evan David Light <evan at tiggerpalace.com> wrote:> Disclaimer: The following are observations by a relatively new user (couple > of weeks) of RSpec and not intended as RSpec trollbait. Also, forgive me if > similar topics have been discussed elsewhere on the mailing list. I at > least did the due diligence of a quick search. > > That said... > > I''ve been positively thrilled with RSpec for use outside of Rails. It has > been in my attempts to use it within Rails that I have begun to question > whether and how it can buy me much more than Test::Unit. > > I recently began using RSpec to drive the design, in BDD fashion, of a > Rails app. Believing that behavior is best measured from the user''s > experience, I started by writing a View spec. I considered this a top-down > approach. Were I still using Test::Unit, I likely would have started in the > same place that I usually do out of habit: the Model. > > However, the more googling that I''ve done, the more that I noticed that > most RSpec articles, where they addressed Rails, were primarily focused on > the Model. I began to wonder, "are people using RSpec much like people were > using Test::Unit?" I''ve seen that some people eschew View Specs. However, > in lieu of that, how does one spec the interface that should, in theory, > drive the design of the application? > > Ultimately, I''m left with similar perspective to Jordan''s: View specs will > be brittle. They''ll span multiple Behaviors as there will be at least one > per action -- leading me to wonder if BDD, or at least RSpec, is necessarily > the best way to try to spec the View. However, Controllers and Models seem > as though they would work reasonably well. > > Can anyone recommend some approaches for tackling BDD starting from the > View down? > > Thanks, > Evan > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >Hi Evan, I think you have the right idea about approaching specification from the user''s viewpoint (or more appropriately, as David C said, business value). It just seems like you''re not completely familiar with the tools that RSpec provides. Nothing wrong with that, because one of the most important tools still hasn''t been officially released! View specs are for unit testing your view, not for exercising functionality. In fact they shouldn''t do very much at all. They should be pretty simple...make sure that certain attributes from an object are being displayed, perhaps how some of the markup is structured, etc. That can be brittle, and will become painfully so if you specify too much. You''ll want to specify the bare minimum it takes to get the job done. Others have mentioned Story Runner, which is a new feature of RSpec. I''m pretty jazzed about it, because it''s a very lightweight tool for acceptance tests. The structure is clean, it just makes sense to me. I wrote an introduction which you can find at http://evang.eli.st/blog/2007/9/1/user-stories-with-rspec-s-story-runner. It also has links to some of Dan North''s articles which are a great resource for really getting BDD. As far as tackling BDD from the top down...for me, it all starts with a Story. This can be a bit tough if you don''t write user stories to define features, and instead just get told "hey we should add this." However I''ve found that writing an initial user story forces me to really clarify what a feature means to our product. Also Story Runner makes it incredibly easy to share the stories with others. If one of our customers tells me something doesn''t work right, but I think it does, I can show him the story I wrote. We''ve already resolved an issue like this...I showed him the story, he said that he was making different assumptions. I coded those up into the story and off we went. I hope you check out Story Runner, it''s a really cool tool. If your development philosophy is about creating business value, then it should totally vibe with you. From there you use the finer-grained aspects of RSpec to achieve that business value with code that doesn''t drive you insane :) Pat
On Sep 13, 2007, at 6:10 PM, Pat Maddox wrote:> On 9/12/07, Evan David Light <evan at tiggerpalace.com> wrote: >> ... (Evan''s RSpec n00bish ramblings) ...>> Thanks, >> Evan >> >> > > Hi Evan, > > I think you have the right idea about approaching specification from > the user''s viewpoint (or more appropriately, as David C said, business > value). It just seems like you''re not completely familiar with the > tools that RSpec provides. Nothing wrong with that, because one of > the most important tools still hasn''t been officially released! >Quite so. Certainly not with RSpec-on-Rails at least. I have been milling around the RDoc. in my spare moments and have written a few specs for a statistical analysis tool that I wrote recently. Work has been dragging me away from coding too much lately. Fortunately, I''ve had this afternoon and have all of tomorrow to get my hands dirty.> View specs are for unit testing your view, not for exercising > functionality. In fact they shouldn''t do very much at all. They > should be pretty simple...make sure that certain attributes from an > object are being displayed, perhaps how some of the markup is > structured, etc. That can be brittle, and will become painfully so if > you specify too much. You''ll want to specify the bare minimum it > takes to get the job done. >Understood. Admittedly, I had not even seen a Rails Integration Test until I after I read a few posts on this list and did some googling. I''ve been fortunate to be able to pick Ruby for my current project but I haven''t had an excuse to develop a production Rails app until a few days ago. I''ve only done a lot of tinkering at home for which I now wish that I had used TDD or BDD. That said...> Others have mentioned Story Runner, which is a new feature of RSpec. > I''m pretty jazzed about it, because it''s a very lightweight tool for > acceptance tests. The structure is clean, it just makes sense to me. > I wrote an introduction which you can find at > http://evang.eli.st/blog/2007/9/1/user-stories-with-rspec-s-story- > runner. > It also has links to some of Dan North''s articles which are a great > resource for really getting BDD. >I know! I saw them both! After reading David''s messages from yesterday, I was inspired to checkout from trunk this afternoon, plowed through some of the spec for Story Runner, and then some of the examples. I love what I see. My immediate impression was Story == Use Case. That seems to be bear out the more that I looked at the RSpec for Story Runner and at the code samples. In fact, I was just getting ready to dig into writing my first Story when I decided to pop over to the mailing list for a second. Who needs to read an RDoc? ;-)> As far as tackling BDD from the top down...for me, it all starts with > a Story.I can totally see that. Use cases tend to proceed lower level requirements in the waterfall process (not that many of us are using this one anymore...).> This can be a bit tough if you don''t write user stories to > define features, and instead just get told "hey we should add this."Not necessarily. Just as you say below, the Story lets you put meat on that skeleton of an idea.> We''ve already resolved an > issue like this...I showed him the story, he said that he was making > different assumptions. I coded those up into the story and off we > went. >Very cool.> I hope you check out Story Runner, it''s a really cool tool. If your > development philosophy is about creating business value, then it > should totally vibe with you. From there you use the finer-grained > aspects of RSpec to achieve that business value with code that doesn''t > drive you insane :)Seriously, this is exactly the kind of thing that I was looking for when I mistakenly began playing with View specs. Now I''m also going to have to "Storify" my personal Rails project when I get some spare time! Thanks guys. This looks like it will be very useful. More as I dig in. Evan Light IMs (all): sleight42 http://evan.tiggerpalace.com
On 9/13/07, Evan David Light <evan at tiggerpalace.com> wrote:> My immediate impression was Story == Use Case.Story == User Story User Stories are not the same thing as Use Cases. You may want to google around for some writing on that. Cheers.
On 14.9.2007, at 1.10, Pat Maddox wrote:> Others have mentioned Story Runner, which is a new feature of RSpec. > I''m pretty jazzed about it, because it''s a very lightweight tool for > acceptance tests. The structure is clean, it just makes sense to me. > I wrote an introduction which you can find at > http://evang.eli.st/blog/2007/9/1/user-stories-with-rspec-s-story- > runner. > It also has links to some of Dan North''s articles which are a great > resource for really getting BDD.+1 for Story Runner. I just installed it on a project for a client that were using controller specs heavily for end-to-end stuff. Even on an app running on Rails 1.2, the rspec trunk installed flawlessly with some minimal changes to the existing spec code. From what I learned, Story Runner is already highly usable even though it''s not officially out. //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/20070914/8ebb7a81/attachment-0001.bin