David Chelimsky wrote: > On Nov 7, 2007 10:18 PM, Ben Mabey <[EMAIL PROTECTED]> wrote: > >> I just ran across this blog which helped me out a lot in answering some >> of my questions about the plain text story runner: >> http://www.kerrybuckley.com/2007/11/07/driving-selenium-from-the-rspec-story-runner-rbehave/ >> > > It's great to see this conversation advancing so quickly, however > please keep in mind that this is all very young and just because > someone blog's something (including ME) doesn't mean that it's "the > way". While Kerry's example is very clean and obviously works well for > him, it does go against the grain of the philosohy that Dan is > espousing: expressing stories in the business domain rather than the > UI domain (btw Dan, that was brilliantly put). What exactly do you and Dan mean when you say that the stories should be expressed in the business domain rather than the UI domain? (BTW, is there a link to a Dan North post abou that?) From my understanding you are saying that the steps that say "user types in such and such" and user "hits the login button" are too UI specific and don't really have much to do with the business domain. Is that correct?
I think that this is a part of writing stories that I am somewhat struggling with, meaning how specific should these stories be in explaining the view? At RubyConf during your presentation (great job, BTW!) you mentioned how you like to spec out your views first. I agree that is is a really nice way to drive the development process. Now with the introduction of the story runner we are now letting the stories drive the process. So my thinking is that you let the stories drive all of the development, including that of the views. Is this assumption wrong? This feels right in one way because I will not be adding a form to a view unless the story specifies it and thereby drives BDD... On the other hand this level of granularity seems a bit overkill and clutters the stories a bit. Where is the happy medium, in your opinion, between keeping the stories concise and letting them drive every aspect of the development? Maybe I am wrong in saying that the stories should drive EVERY aspect of the development? >> The Selenium integration is also an interesting idea that you might want >> to read about if you haven't seen this post. I'm still trying to >> decided if using Selenium is worth the extra effort (my main goal would >> be to test the JS during the acceptance tests) >> > > One cool thing about having the steps disconnected from the expression > of the stories is that you can have more than one implementation of > any given step and use the one you want based on any arbitrary runtime > conditions. There is no direct support for making this decision built > into the Story Framework, but this IS Ruby after all. > > This would theoretically allow you to write stories at an abstract > level and decide whether to run each scenario in memory or in a > browser based on whether or not there is additional business value in > running them in browser. > Yes, good point. The step matchers really do open up a whole new world of possibilities. >> and if the regular rails >> integration testing is good enough. I'd be interested to hear what >> other user's on this list think in terms of Selenium or any other >> browser based framework and there experience with them. >> > > Generally speaking, in-browser tests tend to be incredibly brittle and > run dog-slow. They simply have no choice but to be tied directly to > low-level implementation details like html structure and element IDs. > > So I'd recommend only testing what you absolutely must in-browser. But > given our ajax-laden world, "what you absolutely must" may well turn > out to be a lot! > > FWIW, > David > > > I have heard that Selenium suites can become out of hand and end of being more hassle than what there worth. Thanks for the recommendation, I think that sounds like a sensible one. Thanks for taking the time to discuss this, Ben _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
