What’s the status on a rake task for the story runner. If nothing is
in progress, where could I start to try and build one?
JD
James D. wrote:
What’s the status on a rake task for the story runner. If nothing is
in progress, where could I start to try and build one?JD
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
If you check out rspec trunk you can see that they have created one for
the rspec project. It just runs the all.rb file in the stories
directory.
-Ben
On Dec 19, 2007 7:01 PM, James D. [email protected] wrote:
What’s the status on a rake task for the story runner. If nothing is
in progress, where could I start to try and build one?JD
I’ve been using:
task ‘stories’ do
sh “ruby stories/all.rb”
end
task ‘stories:rcov’ do
sh “rcov -o story_coverage --exclude stories stories/all.rb”
end
Kyle
Ben M. wrote:
This is the actual task they are using:
desc “Run all stories”
task :stories do
html = ‘story_server/prototype/rspec_stories.html’
ruby “stories/all.rb --colour --format plain --format html:#{html}”
unless IO.read(html) =~ //m
raise ‘highlighted parameters are broken in story HTML’
end
end
On 12/19/07, James D. [email protected] wrote:
What’s the status on a rake task for the story runner. If nothing is
in progress, where could I start to try and build one?
Until step/scenario directories are standardized you’re not going to
see a rake task committed.
Feel free to roll your own, I wrote a simple one that just calls all.rb.
–
Josh K.
phone: 509-979-1593
email: [email protected]
web: http://joshknowles.com
What file is that in? I was looking for one in trunk earlier.
JD
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.
JD
On Dec 19, 2007 11:34 PM, James D. [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.
On Dec 19, 2007, at 9:38 PM, David C. wrote:
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
Good enough for me. I just wanted a reason. May I ask how you set them
up?
James D.
On Dec 19, 2007, at 9:44 PM, David C. wrote:
know convention over configuration and all.
stories/stuff_related_to_one_feature
[email protected]
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?
JD
On Dec 19, 2007 11:50 PM, James D. [email protected] wrote:
On Dec 19, 2007 11:34 PM, James D. [email protected]
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 H.'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?
On Dec 19, 2007, at 10:16 PM, David C. wrote:
On Dec 19, 2007, at 9:38 PM, David C. wrote:
what
them
stories/stuff_related_to_yet_another_feature
http://rubyforge.org/mailman/listinfo/rspec-usersHpricot-wrapping goodness. It doesn’t cover javascript, but the apps
end
response.should have_text(/#{message}/)
Then I should see Welcome david
rspec-users mailing list
[email protected]
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.
JD
On Dec 19, 2007 11:40 PM, James D. [email protected] wrote:
Because I think it’s premature to call anything related to story
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?
On Dec 20, 2007 12:25 AM, James D. [email protected] wrote:
On Dec 19, 2007 11:40 PM, James D. [email protected]
know convention over configuration and all.
http://rubyforge.org/mailman/listinfo/rspec-users
stories/steps/ (steps go in here - that seems to be the
Anyhow - that’s where I’m at. How about you?
stories/stories/
I’ve got a bunch of selenium tests being driven by spec/ui. I haven’tclicks_button
When I go to log in
aligned with the fields you’re submitting, you’ll get a failure.
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
On Dec 20, 2007 12:42 AM, Ben M. [email protected] wrote:
regards to bug #188. I am wondering why we don’t standardize
rspec-users mailing list
stories/helper.rbstories/steps/
this:
When “I submit my credentials” doclicks_button method. What this means is that if the form isn’t
Um… Sweetness!!! How is it for speed? There is a ton of stuff we
Yeah, I’m curious about speed as well. We decided not to switch over to
webrat because we thought that using hpricot on all of the tests would
slow things down compared to the regular assert_select and other
integration helpers. Is there much of a speed difference?
I haven’t compared directly - I would have to assume it’s slower not
necessarily because of hpricot, but because of the strategy of tying
the inputs to the form and building the post from the html. But that
is very, very comforting - especially in integration tests. Without
that, assert_select leaves you with the same problems that mocks do -
you could get all your isolation tests to pass, but integration fails.
On Dec 19, 2007, at 10:42 PM, David C. wrote:
On Dec 19, 2007, at 9:44 PM, David C. wrote:
Yeah, had a slight email conversation with David C about that
orSo in this case, the only thing that would be consistent across
I’ve been doing a feature per file. So I have:
is.
I’ve been working on have been very vanilla with respect to ajax, soend
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.
Not a bad idea. Our tests are in terrible condition due to the length
of time it takes to run selenium.
forward to the opportunity to.
I’ll look into it. Thanks for the pointer!
James D. wrote:
wrote:
know convention over configuration and all.
http://rubyforge.org/mailman/listinfo/rspec-users
“convention”)
converted them to stories yet.
end
And I enter Username: davidand database persistance.
JD
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
Yeah, I’m curious about speed as well. We decided not to switch over to
webrat because we thought that using hpricot on all of the tests would
slow things down compared to the regular assert_select and other
integration helpers. Is there much of a speed difference?
-Ben
On Dec 19, 2007, at 10:42 PM, David C. wrote:
On Dec 19, 2007, at 9:44 PM, David C. wrote:
Yeah, had a slight email conversation with David C about that
orSo in this case, the only thing that would be consistent across
I’ve been doing a feature per file. So I have:
is.
I’ve been working on have been very vanilla with respect to ajax, soend
Obviously it’s much faster than running stuff in a browser. I have
shows a lot of promise called crosscheck
Cheers,
David
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
Can you show me how you set up for webrat? I can’t get the story
runner to recognize webrat. I have require ‘webrat’ in helper.rb, and
then I’m trying to use visits, and it fails!
JD
On Dec 21, 2007 6:16 PM, James D. [email protected] wrote:
Can you show me how you set up for webrat? I can’t get the story
runner to recognize webrat. I have require ‘webrat’ in helper.rb, and
then I’m trying to use visits, and it fails!
Actually, you shouldn’t need to add an include to helper.rb because
Webrat’s init.rb loads it automatically when in the test environment.
Can you email me off-list with a stacktrace?
Thanks,
Thanks for the endorsement, David.
Just wanted to mention that I’d be very interested in optimizing the
internals of Webrat for performance down the road if necessary. We’re
not tied to Hpricot by the API, so swapping it out for a faster parser
would be fine if it produces a speed gain. My first goal was to nail
the approach and get a good API.
In the mean time, in my experience it is quite fast, and I’m
personally quite picky about test speed. When I’ve got more concrete
benchmarks on a larger test suite, I’ll post them.