I've shared my solution here in case it's of
interest: https://gist.github.com/1178383
I don't like the use of reload_routes! but it seems to do the trick.
Regards, Nick
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman
Hi David
Something like:
Given I am a user about to receive an arbitrary flash notice
When I visit one of the application's static pages which has not yet been
cached
Then I should not see my flash notice in the page
And another user should not see my flash notice when they visit the same
pag
I'm trying to test that "static" pages (they're ERB, but get cached),
generated through rails, don't render any stray flash notices left over by
the authentication system (Devise) or wherever else.
I've tried writing this controller spec, but it appears that response.body
only renders the templ
amples from with that
though, do you mean redefining lets inside of the shared example
groups, or something else?
Cheers,
Nick
On Jul 30, 11:13 pm, Ashley Moran
wrote:
> On 30 Jul 2010, at 10:00 PM, nruth wrote:
>
> >http://gist.github.com/501296
>
> > I don't think anythi
+ an inner describe) might help flag it as a possible pitfall.
Thanks,
Nick
On Jul 29, 1:22 am, David Chelimsky wrote:
> On Jul 28, 2010, at 5:42 PM, nruth wrote:
>
>
>
>
>
> > Please correct me if this is fixed in Rspec 2, but in Rspec 1 I have
> > hit upon the followin
Please correct me if this is fixed in Rspec 2, but in Rspec 1 I have
hit upon the following problem (at least thrice, this time it costing
me several hours), code is the best example:
I have a practice examination system where each record is one of
several "subtests" (think tagging rather than sub
I'm setting up a Paypal IPN listener and need the create action to not
use rails' default CSRF protection.
I've got that working fine & test it actually works with cucumber
(where I've turned CSRF back on, since it's full-stack testing) but
would like my controller spec to mention the need for
pro
Steve, I'm trying to persuade myself, or rather be persuaded by
someone who knows better.
Since writing this I got an update of the RSpec book and noted that
chapter 23 has been rewritten to discuss this. That's great, as the
version I had really didn't cover it at all. Thumbs up to David et al
fo
Hi Guys
I'm going to put the cat amongst the pigeons here in the hope of some
clarity falling out of the sky on me.
My question is this: In a world with Cucumber what is the value of
view specs?
In the community (railscamp, for example) there are a fair number of
people using Cucumber and skippin
after all. :)
Cheers
Nick
On Sep 22, 2:52 pm, Stephen Eley wrote:
> On Tue, Sep 22, 2009 at 8:55 AM, nruth wrote:
>
> > I guess the short answer is no, stop being silly, [...]
>
> It wasn't silly at all to raise the question. I apologize sincerely
> if I gave the impressi
looking the same or worse.
Still, I found it interesting. Thanks for the feedback.
Running under the fence indeed, which hedge do these faults and
failures creep out from ;)
Nick
On Sep 22, 6:38 am, Stephen Eley wrote:
> On Sun, Sep 20, 2009 at 9:34 PM, nruth wrote:
>
> > We're using a
If you want a quick intro it's worth looking on http://www.slideshare.net/
for some intro talks at the many Rails conventions that have been held
recently. Try searching for cucumber or rspec and see what falls out.
There are videos of presentations out there too, for example
http://www.engineyard
index, request
end
where as_a_visitor handles the stubbing and returns the documentation
string?
On Sep 21, 2:50 am, nruth wrote:
> My last reply seems to have been swallowed by the Ajax monster.
>
> In brief, my suggestion is just for readability/maintenance. I feel
> the describe/context and
r than the tools to
write legible specs.
Thanks for the reply
Cheers
Nick
On Sep 20, 9:56 pm, David Chelimsky wrote:
> On Sun, Sep 20, 2009 at 9:38 AM, nruth wrote:
> > I've been reading through the Rspec book to see if I missed any
> > tricks, and the discussion of before
m, David Chelimsky wrote:
> On Sun, Sep 20, 2009 at 9:38 AM, nruth wrote:
> > I've been reading through the Rspec book to see if I missed any
> > tricks, and the discussion of before block use for context setup in
> > sec 12.6 struck me as interesting and something I had
I've been reading through the Rspec book to see if I missed any
tricks, and the discussion of before block use for context setup in
sec 12.6 struck me as interesting and something I had a knee-jerk
reaction to.
I think that when you are using nested examples to describe a context
change it is bad
I'd appreciate suggestions for improving this matcher. Currently it
relies on the link saying "Delete", not whether it sends a delete
request when used.
def have_delete_link(href)
simple_matcher("a link href='#{href}'") do |given|
selector = have_selector("a[href='#{href}']", :co
17 matches
Mail list logo
