On 8 Feb 2010, at 16:53, David Chelimsky wrote:
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.
So maybe we just need to build a library of helpers that make it easy
to create a modified rails app in Cucumber features?
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
cheers,
Matt
http://mattwynne.net
+447974 430184
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
