On Dec 20, 2007 12:25 AM, James Deville <[EMAIL PROTECTED]> wrote: > > > On Dec 19, 2007, at 10:16 PM, David Chelimsky wrote: > > > On Dec 19, 2007 11:50 PM, James Deville <[EMAIL PROTECTED]> > > wrote: > >> > >> > >> On Dec 19, 2007, at 9:44 PM, David Chelimsky wrote: > >> > >>> On Dec 19, 2007 11:40 PM, James Deville <[EMAIL PROTECTED]> > >>> wrote: > >>>> > >>>> > >>>> On Dec 19, 2007, at 9:38 PM, David Chelimsky wrote: > >>>> > >>>>> On Dec 19, 2007 11:34 PM, James Deville <[EMAIL PROTECTED]> > >>>>> wrote: > >>>>>> Yeah, had a slight email conversation with David C about that in > >>>>>> regards to bug #188. I am wondering why we don't standardize > >>>>>> it, ya > >>>>>> know convention over configuration and all. > >>>>> > >>>>> Because I think it's premature to call anything related to story > >>>>> runner a convention. I actually organize them differently from > >>>>> what > >>>>> many are calling convention, and my way is not necessarily "right" > >>>>> or > >>>>> "better." Let's wait a while on this. We'll get there. > >>>>> _______________________________________________ > >>>>> rspec-users mailing list > >>>>> rspec-users@rubyforge.org > >>>>> http://rubyforge.org/mailman/listinfo/rspec-users > >>>> > >>>> > >>>> Good enough for me. I just wanted a reason. May I ask how you set > >>>> them > >>>> up? > >>> > >>> Sure. > >>> > >>> stories/ > >>> stories/helper.rb > >>> stories/steps/ (steps go in here - that seems to be the > >>> "convention") > >>> stories/stuff_related_to_one_feature > >>> stories/stuff_related_to_another_feature > >>> stories/stuff_related_to_yet_another_feature > >>> > >>> So in this case, the only thing that would be consistent across > >>> projects would be helper.rb and the steps directory. Even that > >>> should > >>> probably be called step_definitions or something. I'm not sure. > >>> > >>> Anyhow - that's where I'm at. How about you? > >>> _______________________________________________ > >>> rspec-users mailing list > >>> rspec-users@rubyforge.org > >>> http://rubyforge.org/mailman/listinfo/rspec-users > >> > >> I've been doing a feature per file. So I have: > >> > >> stories/ > >> stories/helper.rb > >> stories/steps/ > >> stories/stories/ > >> > >> So in stories/stories I have my stories with multiple scenarios per > >> story. > >> > >> I'm definitely seeing your point, and the reason for leaving it as > >> is. > >> > >> Do you use selenium or anything like that via the stories? If not, > >> what kinds of things do you test with stories? > > > > I've got a bunch of selenium tests being driven by spec/ui. I haven't > > converted them to stories yet. > > > > Mostly I've been using webrat, Bryan Helmkamp's awesome > > Hpricot-wrapping goodness. It doesn't cover javascript, but the apps > > I've been working on have been very vanilla with respect to ajax, so > > I've been satisfied with have_rjs. > > > > Anyhow, webrat does something really cool - it ties your form > > submissions to the html of the rendered form. So you make steps like > > this: > > > > ===================== > > When "I go to log in" do > > visits "/session/new" > > end > > > > When "I enter $label: $value" do |label, value| > > fills_in label, :with => value > > end > > > > When "I submit my credentials" do > > clicks_button > > end > > > > Then "I should see $message" do |message| > > response.should have_text(/#{message}/) > > end > > ===================== > > > > And a scenario like this: > > > > ===================== > > When I go to log in > > And I enter Username: david > > And I enter Password: webrat rules > > And I submit my credentials > > Then I should see Welcome david > > ===================== > > > > And what webrat does is grabs the html from the response in the visits > > method, modifies that html with your data in the fills_in method, and > > then yanks the data from the html and submits it with the > > clicks_button method. What this means is that if the form isn't > > aligned with the fields you're submitting, you'll get a failure. > > > > How clean is that? > > _______________________________________________ > > rspec-users mailing list > > rspec-users@rubyforge.org > > http://rubyforge.org/mailman/listinfo/rspec-users > > > Um... Sweetness!!! How is it for speed? There is a ton of stuff we > would love to move out of Selenium due to issues with sessions, flash, > and database persistance.
Obviously it's much faster than running stuff in a browser. I have nothing else to measure it against and haven't done any real benchmarking, but it is perceivably much faster than running selenium. What I'd recommend - where I'm headed as the opportunity presents itself - is to have in-memory and in-browser implementations of the same steps. Then you can run them in-memory most of the time and skip the javascript, but run them in-browser once in a while - like before commits - to make sure the javascript is all working too. There's also an interesting javascript testing framework that I think shows a lot of promise called crosscheck (http://www.thefrontside.net/crosscheck). It's basically got it's own browser-less javascript engines and runs in-memory. Last I heard it was mostly dead-on, but that it missed some things. The guy who told me that said he was running selenium for a few things that crosscheck didn't do right, but I don't know what those are :) I did toy with it for a minute, and it's blazingly fast. I just haven't made a commitment to use it in anger yet - but I'm looking forward to the opportunity to. Cheers, David _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
