On 18 Mar 2008, at 19:38, Kyle Hargraves wrote:
> config.load_paths += Dir[File.join('vendor', 'gems', '*',
> 'lib')].map do |libdir|
> File.expand_path(libdir)
> end
>
> This'll let it be loaded as a gem and you can put this in spec_helper:
>
> require 'rspec_hpricot_matchers'
> Spec::Runner.configure do |config|
> config.include(RspecHpricotMatchers)
> end
Ah that's neater than my way. Forgot about the Rails load path.
Don't use rails regularly enough to memorise all these tricks...
> I really like your undef magic for disabling the rspec_on_rails
> matchers; hadn't thought of doing that.
>
> One problem you will run into, I'm sure, is nested expectation
> failure messages:
>
> body.should have_tag('ul') do |ul|
> ul.should have_tag('li')
> end
>
> Fails with "expected body to have tag 'ul'", even if it's the inner
> 'li' that was missing. I haven't come up with a good way to fix this,
> but it's very annoying!
Yep that one caught me! I'd like a neater solution too, not sure how
though. Just had a look at the code and it doesn't look easy.
Because RSpec raises exceptions on your behalf when a match fails, you
only get chance to set the message and not tag any extra information
on there. Short of a really ugly hack, the only way round this I can
see would be extend RSpec's ExpectationMatcherHandler and Expectation
to support retrieving another object from the matcher to go with
failure_message (maybe failure_data). Then you could collect those as
the exceptions bubble up to the top level matcher.
Or for a kludge you could subclass HpricotMatcherString < String,
attach the failures to it and pass instances of that up as failure
messages instead of plain strings. Nasty nasty nasty, but it would
give you everthing you need to generate a detailed message at the top.
Ashley
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
