On Mon, Feb 8, 2010 at 11:58 AM, Phillip Koebbe <phillipkoe...@gmail.com> wrote:
> Matt Wynne wrote:
>>
>> Yeah, you need to convince RSpec that the describe blocks you're using are
>> describing an ExampleGroup that's about a Rails Controller, then it will mix
>> in the right methods for you. I think you can do something like:
>>
>> describe MySpecialTestController, :type => :controller do
>> end
>>
>> That's the general idea. I think someone else on the list will be able to
>> help more than me with the specifics.
>>
>> As for a plug-in, I don't know any off-hand... try a few popular ones out
>> on github and look for a spec directory in the root I guess.
>>
>
> Thanks, again, Matt for taking the time to respond. I was kind of surprised
> by how many plugins use test::unit. I did finally find subdomain_fu [1] and
> was able to get something working. However, this approach tests the
> controller in a project and requires rspec-rails to be installed for the
> project. I would really like to be able to test this independent of a
> project. So if anyone knows how to test a controller plugin with RSpec
> independent of a project, I'd really appreciate some pointers.
The problem I've run into in trying to spec controller extensions in
isolation is that Rails controllers are not self-contained objects:
they need a bunch of surrounding state set up for them to work
properly. The testing facilities that ship with Rails hide that all
from you, but they do a lot of work for you in every test method, or
rspec code example.
In theory, you should be able to say:
=================================
require 'rubygems'
require 'action_controller/base'
class SomeController < ActionController::Base
def index
render :text => "this text"
end
end
describe SomeController do
describe "index" do
it "returns some text" do
c = SomeController.new
c.index.should == "this text"
end
end
end
=================================
When you do, however, you get this:
uninitialized constant ActionController::Metal (NameError)
Try to solve that and you'll be starting down a deep rabbit hole. And
even if you do solve that, the next rails release may well break
whatever you did to solve it. The safest bet is to spec your plugin in
the context of a complete rails app.
That said, I'd love to make this easier to do with rspec, but I won't
have cycles to drive this for quite some time. If anyone else is
interested in driving this, speak up and I'll be happy to assist.
Cheers,
David
>
> Here's what I have right now:
>
> http://gist.github.com/298281
>
> Thanks,
> Phillip
>
>
> [1] http://github.com/mbleigh/subdomain-fu
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
