Re: [rspec-users] Weird failing spec

2007-10-27 Thread Tarsoly András 

On 2007.10.27., at 7:18, David Chelimsky wrote:

> and_raise(ActiveRecord::RecordInvalid.new(@option))
>
> Sorry if I led you astray on that one.
>

No problems, actually it makes perfect sense, since you want @option  
to have all the proper error messages and such.

After adjusting the specs like this one, it was all working fine and  
dandy as soon as I stubbed the .errors.full_messages() call.

This raises up a question in me about mocking or using real-life  
models, because in some of my specs the setups getting extremely  
bulky. But this is for another topic :)

Cheers,
András

--
Tarsoly András
[EMAIL PROTECTED]



___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Examples of writing controller specs that use authentication

2007-10-27 Thread Jarkko Laine 

On 27.10.2007, at 8.54, Pat Maddox wrote:

> On 10/26/07, Leslie Freeman <[EMAIL PROTECTED]> wrote:
>> Hello,
>> I'm working on specs for a controller that handles authentication
>> using the restful_authentication plugin. I'm trying to find a
>> resource (tutorial or examples, if possible) about the best way to go
>> about writing mocks and specs to make sure that things like my
>> before_filters are working correctly. Does anyone know of any good
>> resources for this?
>>
>> Thanks,
>> Les
>> ___
>> rspec-users mailing list
>> rspec-users@rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
> To make sure that the filter works when you're not logged in, just
> make the request:
>
> describe CategoriesController, " POST /categories, not logged in" do
>   it "should redirect to the login url" do
> post :create, :category => {"name" => "foo"}
> response.should redirect_to(login_url)
>   end
> end
>
> and when you want to spec the meat of the request, stub the  
> logged_in? method:

Or, if you need different users to behave in different ways, you  
might want to create a helper in spec_helper.rb, such as this:

   def login_as(user, options = {:id => "5", :needs_activation => false,
 :admin => false})
 user.stub!(:id).and_return(options[:id])
 user.stub!(:to_param).and_return(options[:id])
 user.stub!(:needs_activation?).and_return(options 
[:needs_activation])
 user.stub!(:admin?).and_return(options[:admin])
 controller.send :current_user=, user
   end

Then you can just say this in the specs:

login_as(@user_mock_object)

and the controller will behave accordingly (assuming you use  
restful_authentication/acts_as_authenticated).

//jarkko

--
Jarkko Laine
http://jlaine.net
http://dotherightthing.com
http://www.railsecommerce.com
http://odesign.fi


___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Weird failing spec

2007-10-27 Thread Ashley Moran 

On Oct 27, 2007, at 9:45 am, Tarsoly András wrote:

> This raises up a question in me about mocking or using real-life
> models, because in some of my specs the setups getting extremely
> bulky. But this is for another topic :)

Well while you have everyone's attention :)

Often you can factor out the setup code - if you search through the  
archives of this list there's plenty of examples.  But don't worry  
about having long setups - I've written some setups that aren't much  
shorter than the specs that follow.  Write whatever setup you need to  
enable you to write solid specs, then worry after about making it  
look nice.

I would say you should ALWAYS mock your models in your controllers  
specs.  Otherwise you will further complicate your setups, make your  
specs run unacceptably slow, and you risk coupling your controllers  
and models too tightly.  Many people in the BDD community (and at a  
guess I am assuming David is among them) would frown on using  
database access in your *model* code, because persistence is a  
separate issue to business logic.

What you want is a set of specs for each of model (ideally, database  
persistence and business logic separately), controller, and view, and  
then an integration test, such as an RSpec story, that tests the full  
stack.  Without this integration step, you will miss errors when you  
change the interface of a model.  What you do not want is the Rails  
way of testing, where each layer of testing re-tests everything below  
it.  (I recently saw a blog post where someone asked for comments on  
how people test views in isolation - it never occurred to me that  
some Rails developers still see that as an issue!)

Having thought about it, you could argue Rail has no *unit* testing  
support built in at all.

Ashley


-- 
blog @ http://aviewfromafar.net/
linked-in @ http://www.linkedin.com/in/ashleymoran
currently @ home


___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Weird failing spec

2007-10-27 Thread David Chelimsky 
On 10/27/07, Ashley Moran <[EMAIL PROTECTED]> wrote:
> On Oct 27, 2007, at 9:45 am, Tarsoly András wrote:
>
> > This raises up a question in me about mocking or using real-life
> > models, because in some of my specs the setups getting extremely
> > bulky. But this is for another topic :)

Bulky setup is a design smell. That doesn't mean it never happens, but
when it does you should ask yourself what you can do to improve the
design. If you're not familiar with the Law of Demeter, search around
for it and give it some thought.

> Well while you have everyone's attention :)
>
> Often you can factor out the setup code - if you search through the
> archives of this list there's plenty of examples.  But don't worry
> about having long setups - I've written some setups that aren't much
> shorter than the specs that follow.  Write whatever setup you need to
> enable you to write solid specs, then worry after about making it
> look nice.

In spite of what I said earlier, this is true. For specs, coming from
TDD, "the way" is to get from red to green and then refactor. The
refactoring step should be considered every time you get to green.
Where is duplication? How can I improve the design to eliminate it?
You won't always actually do anything, but the thought process is very
important. It's like a 24/7 design review.

> I would say you should ALWAYS mock your models in your controllers
> specs.  Otherwise you will further complicate your setups, make your
> specs run unacceptably slow, and you risk coupling your controllers
> and models too tightly.  Many people in the BDD community (and at a
> guess I am assuming David is among them) would frown on using
> database access in your *model* code, because persistence is a
> separate issue to business logic.

If I were writing the framework, this would be true. But Rails
provides efficiencies in exchange for blending these concepts in to
one. It's a trade off, but I've come to appreciate the efficiencies
enough where I live with it.

> What you want is a set of specs for each of model (ideally, database
> persistence and business logic separately

Do you mean like this?

spec/models-persistence
spec/models-business_logic

Or do you just mean separating the concerns within a single spec document?

> ), controller, and view, and
> then an integration test, such as an RSpec story, that tests the full
> stack.  Without this integration step, you will miss errors when you
> change the interface of a model.  What you do not want is the Rails
> way of testing, where each layer of testing re-tests everything below
> it.  (I recently saw a blog post where someone asked for comments on
> how people test views in isolation - it never occurred to me that
> some Rails developers still see that as an issue!)
>
> Having thought about it, you could argue Rail has no *unit* testing
> support built in at all.

Absolutely agree. You have to go some distance to do any real unit
testing in Rails. But, on the flip side, you get so much for free that
you get from other more highly-decoupled framework that it might be
worth the trade-off. There's a balance in there somewhere ... let me
know when you find it :)

Cheers,
David
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

[rspec-users] Strange warnings with view specs

2007-10-27 Thread Scott Taylor 

I've been seeing the following in some of my view specs:

.P.Pignoring attempt to close spec::mocks::mock:0x7334c4c  
with td
   opened at byte 258, line 20
   closed at byte 287, line 20
   attributes at open: {}
   text around open: "\t\n\t\n\t\t#\n\t\t# #s\n\t\t#http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Strange warnings with view specs

2007-10-27 Thread David Chelimsky 
invalid XHTML.

This is coming from rails.

On 10/27/07, Scott Taylor <[EMAIL PROTECTED]> wrote:
>
> I've been seeing the following in some of my view specs:
>
> .P.Pignoring attempt to close spec::mocks::mock:0x7334c4c
> with td
>opened at byte 258, line 20
>closed at byte 287, line 20
>attributes at open: {}
>text around open: "\t\n\t\n\t\t#text around close: "cks::Mock:0x7334c4c>\n\t\t# ignoring attempt to close spec::mocks::mock:0x7334c4c with td
>opened at byte 331, line 21
>closed at byte 361, line 21
>attributes at open: {}
>text around open: "s::Mock:0x7334c4c> #text around close: "ks::Mock:0x7334c4c>s\n\t\t#
>
> Does this indicate non valid XHTML, or is the error elsewhere?
>
> Scott
>
> ___
> 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

[rspec-users] rake spec:rcov failing

2007-10-27 Thread Scott Taylor 

Running rails 1.2.3, rcov (0.8.0.2), rspec trunk (2865) -

When running rake spec:rcov, I'm getting the following:

Finished in 245.717813 seconds

856 examples, 0 failures, 48 pending
/usr/local/lib/ruby/1.8/rexml/text.rb:292:in `normalize': private  
method `gsub' called for 0:Fixnum (NoMethodError)
 from /usr/local/lib/ruby/1.8/rexml/element.rb:1084:in `[]='
 from /usr/local/lib/ruby/1.8/rexml/element.rb:586:in  
`add_attribute'
 from (eval):490:in `table_'
 from (eval):490:in `each'
 from (eval):490:in `table_'
 from (eval):490:in `each'
 from (eval):490:in `table_'
 from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov/ 
report.rb:702:in `format_overview'
  ... 61 levels...
 from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/ 
rcov.rb:628:in `dump_coverage_info'
 from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/ 
rcov.rb:628:in `each'
 from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/ 
rcov.rb:628:in `dump_coverage_info'
 from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov: 
405

Any ideas, or should I report this in the tracker?

Scott
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Strange warnings with view specs

2007-10-27 Thread Scott Taylor 

On Oct 27, 2007, at 1:20 PM, David Chelimsky wrote:

> invalid XHTML.
>
> This is coming from rails.

More or less what I figured.  Thanks

Scott



___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] rake spec:rcov failing

2007-10-27 Thread aslak hellesoy 
Since there is nothing RSpec in the backtrace this look like an RCov
or REXML bug

Aslak

On 10/27/07, Scott Taylor <[EMAIL PROTECTED]> wrote:
>
> Running rails 1.2.3, rcov (0.8.0.2), rspec trunk (2865) -
>
> When running rake spec:rcov, I'm getting the following:
>
> Finished in 245.717813 seconds
>
> 856 examples, 0 failures, 48 pending
> /usr/local/lib/ruby/1.8/rexml/text.rb:292:in `normalize': private
> method `gsub' called for 0:Fixnum (NoMethodError)
>  from /usr/local/lib/ruby/1.8/rexml/element.rb:1084:in `[]='
>  from /usr/local/lib/ruby/1.8/rexml/element.rb:586:in
> `add_attribute'
>  from (eval):490:in `table_'
>  from (eval):490:in `each'
>  from (eval):490:in `table_'
>  from (eval):490:in `each'
>  from (eval):490:in `table_'
>  from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/rcov/
> report.rb:702:in `format_overview'
>   ... 61 levels...
>  from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/
> rcov.rb:628:in `dump_coverage_info'
>  from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/
> rcov.rb:628:in `each'
>  from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/lib/
> rcov.rb:628:in `dump_coverage_info'
>  from /usr/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:
> 405
>
> Any ideas, or should I report this in the tracker?
>
> Scott
> ___
> 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

Re: [rspec-users] rake spec:rcov failing

2007-10-27 Thread Scott Taylor 

On Oct 27, 2007, at 5:10 PM, aslak hellesoy wrote:

> Since there is nothing RSpec in the backtrace this look like an RCov
> or REXML bug
>

Maybe it relates to the invalid XHTML.  I'll report back when that is  
fixed.

Thanks Aslak,

Scott

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] Weird failing spec

2007-10-27 Thread Ashley Moran 

On Oct 27, 2007, at 3:36 pm, David Chelimsky wrote:

> Bulky setup is a design smell. That doesn't mean it never happens, but
> when it does you should ask yourself what you can do to improve the
> design. If you're not familiar with the Law of Demeter, search around
> for it and give it some thought.

I don't think I have any LoD violations in my long setups.  It's just  
the sheer number of things that some pages need to load.  It's  
actually a while since I looked over the code I am referring to.  It  
may actually just be view specs I am thinking of, where bulky setups  
are just a sign of the number of different things being displayed.   
But either way, I'll be vigilant when I return to them.


> In spite of what I said earlier, this is true. For specs, coming from
> TDD, "the way" is to get from red to green and then refactor. The
> refactoring step should be considered every time you get to green.
> Where is duplication? How can I improve the design to eliminate it?
> You won't always actually do anything, but the thought process is very
> important. It's like a 24/7 design review.

I just watched this today: 

Nothing revolutionary if you've been doing BDD in Ruby a while, but  
one of the things he drives home is the idea that in Ruby (and  
dynamic languages in general), you must have the shortest possible  
cycles, and must always work to make sure quality of the code is  
maintained as high as you can manage.

It's puzzling looking at developers who don't do BDD, who think that  
refactoring is something you do when adding a new feature would cause  
the collapse of half the application.  I don't know how they live  
with (a) the stress of leaving a mess behind them and (b) the  
impending nervous breakdown when they actually have to fix it (with  
nothing to tell them it still works!)  I dread to look at some of the  
code that is developed with none of the principles you describe  
above.  Hell, mine is bad enough sometimes and I make the effort.


>> Many people in the BDD community (and at a
>> guess I am assuming David is among them) would frown on using
>> database access in your *model* code, because persistence is a
>> separate issue to business logic.
>
> If I were writing the framework, this would be true. But Rails
> provides efficiencies in exchange for blending these concepts in to
> one. It's a trade off, but I've come to appreciate the efficiencies
> enough where I live with it.

You've become unusually forgiving lately :)


>> What you want is a set of specs for each of model (ideally, database
>> persistence and business logic separately
>
> Do you mean like this?
>
> spec/models-persistence
> spec/models-business_logic
>
> Or do you just mean separating the concerns within a single spec  
> document?

I'd never thought about splitting them into directories like that.   
Currently I just make sure that associations have a separate spec  
block to the others, something like

describe MyModel do
   # ...
end

describe MyModel, "associations" do
   # ...
end

There's probably not so much to do with ActiveRecord, because your  
models HAVE to map directly to tables.  But I still test separately  
the persistence of any custom methods that build object graphs.


> Absolutely agree. You have to go some distance to do any real unit
> testing in Rails. But, on the flip side, you get so much for free that
> you get from other more highly-decoupled framework that it might be
> worth the trade-off. There's a balance in there somewhere ... let me
> know when you find it :)

I still believe that Ruby is powerful enough that we can build highly- 
decoupled frameworks that collapse down to the simple cases by  
default.  Something that has Rails' beauty on the inside as well as  
the outside.  I'll let you know when I find *that*!

Ashley


-- 
blog @ http://aviewfromafar.net/
linked-in @ http://www.linkedin.com/in/ashleymoran
currently @ home

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

[rspec-users] spec_distributed with rails

2007-10-27 Thread Scott Taylor 

Is this the appropriate place to talk about spec_distributed?  If  
not, I'll post the spec-ext (seemingly dead) mailing list on  
rubyforge...

I was able to run a non-rails project with  
Spec::Distributed::RindaSlaveRunner (and RindaMasterRunner).  But I'm  
stumped on how to do it with a rails project, when I have rspec trunk  
installed.  I continue to get wrong error arguments, like the following:

escher: ruby -Ilib script/spec spec/models/* --require spec/ 
distributed --runner Spec::Distributed::RindaSlaveRunner
/Users/smt/src/web/urbis/trunk/vendor/plugins/rspec/lib/spec/runner/ 
options.rb:74:in `run': wrong number of arguments (0 for 2)  
(ArgumentError)
 from /Users/smt/src/web/urbis/trunk/vendor/plugins/rspec/lib/ 
spec/runner/options.rb:74:in `run_examples'
 from /Users/smt/src/web/urbis/trunk/vendor/plugins/rspec/lib/ 
spec/runner/command_line.rb:22:in `run'
 from script/spec:4


Has anyone else used this?  Any tips? (Also, I've run script/generate  
rspec since the last revision)

Scott

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] spec_distributed with rails

2007-10-27 Thread David Chelimsky 
On 10/27/07, Scott Taylor <[EMAIL PROTECTED]> wrote:
>
> Is this the appropriate place to talk about spec_distributed?  If
> not, I'll post the spec-ext (seemingly dead) mailing list on
> rubyforge...
>
> I was able to run a non-rails project with
> Spec::Distributed::RindaSlaveRunner (and RindaMasterRunner).  But I'm
> stumped on how to do it with a rails project, when I have rspec trunk
> installed.  I continue to get wrong error arguments, like the following:
>
> escher: ruby -Ilib script/spec spec/models/* --require spec/
> distributed --runner Spec::Distributed::RindaSlaveRunner
> /Users/smt/src/web/urbis/trunk/vendor/plugins/rspec/lib/spec/runner/
> options.rb:74:in `run': wrong number of arguments (0 for 2)
> (ArgumentError)
>  from /Users/smt/src/web/urbis/trunk/vendor/plugins/rspec/lib/
> spec/runner/options.rb:74:in `run_examples'
>  from /Users/smt/src/web/urbis/trunk/vendor/plugins/rspec/lib/
> spec/runner/command_line.rb:22:in `run'
>  from script/spec:4
>
>
> Has anyone else used this?  Any tips? (Also, I've run script/generate
> rspec since the last revision)

I know Aslak has been using spec/distributed on a significant rails
project, so I'm sure it's workable. I haven't used it myself so I
can't offer you details. But it should work.
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] spec_distributed with rails

2007-10-27 Thread Scott Taylor 

On Oct 27, 2007, at 7:31 PM, David Chelimsky wrote:

> On 10/27/07, Scott Taylor <[EMAIL PROTECTED]> wrote:
>>
>> Is this the appropriate place to talk about spec_distributed?  If
>> not, I'll post the spec-ext (seemingly dead) mailing list on
>> rubyforge...
>>
>> I was able to run a non-rails project with
>> Spec::Distributed::RindaSlaveRunner (and RindaMasterRunner).  But I'm
>> stumped on how to do it with a rails project, when I have rspec trunk
>> installed.  I continue to get wrong error arguments, like the  
>> following:
>>
>> escher: ruby -Ilib script/spec spec/models/* --require spec/
>> distributed --runner Spec::Distributed::RindaSlaveRunner
>> /Users/smt/src/web/urbis/trunk/vendor/plugins/rspec/lib/spec/runner/
>> options.rb:74:in `run': wrong number of arguments (0 for 2)
>> (ArgumentError)
>>  from /Users/smt/src/web/urbis/trunk/vendor/plugins/rspec/ 
>> lib/
>> spec/runner/options.rb:74:in `run_examples'
>>  from /Users/smt/src/web/urbis/trunk/vendor/plugins/rspec/ 
>> lib/
>> spec/runner/command_line.rb:22:in `run'
>>  from script/spec:4
>>
>>
>> Has anyone else used this?  Any tips? (Also, I've run script/generate
>> rspec since the last revision)
>
> I know Aslak has been using spec/distributed on a significant rails
> project, so I'm sure it's workable. I haven't used it myself so I
> can't offer you details. But it should work.

But I guess that you can't run it before you actually commit changes,  
correct? (looking for Aslak's input here, or anyone else...).  If  
that's the case, it seems like it would only be useful for a cluster  
of CI servers.

Scott

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

[rspec-users] failing test with nested controller routes

2007-10-27 Thread Nola Stowe 
I have googled and browsed through spec-users archives, but didn't
find anything different.

I used rspec scaffold command to generate a mvc for groups, I used
nested controller so I could have a separate interface for admin.

the specs are the same as generated, so I won't post the whole thing.
I did put the  nested routes names on the calls to the name routes:

  it "should redirect to the new group on successful save" do
post_with_successful_save
response.should redirect_to(admin_group_url("1"))
  end

the error:
1)
'Admin::GroupsController handling POST /admin/groups should redirect to the new
group on successful save' FAILED
expected redirect to "http://test.host/admin/groups/1";, got redirect to "http://
test.host/groups/1"
./spec/controllers/admin/groups_controller_spec.rb:246:



test log:

Processing GroupsController#update (for 0.0.0.0 at 2007-10-27 21:53:44) [PUT]
  Session ID:
  Parameters: {"action"=>"update", "id"=>"1", "controller"=>"admin/groups"}
Redirected to http://test.host/groups/1
Completed in 0.00061 (1647 reqs/sec) | DB: 0.0 (0%) | 302 Found
[http://test.host/admin/groups/1]

it get redirected to http://test.host/groups/1 instead of admin/groups/1

It does work in the interface, which makes me believe that its not in
rails but something in rspec:
dev log:

Processing GroupsController#create (for 127.0.0.1 at 2007-10-27 22:04:00) [POST]
  Session ID: 082b2f0103579493d5aa2a2851b4e721
  Parameters: {"commit"=>"Create", "action"=>"create",
"controller"=>"admin/groups", "group"=>{...}}
  SQL (0.000337)   INSERT INTO groups (...)
Redirected to http://127.0.0.1:3000/admin/groups/4
Completed in 0.02443 (40 reqs/sec) | DB: 0.00034 (1%) | 302 Found
[http://127.0.0.1/admin/groups]

it works... so the route works.. but not in the test?

here's whats in my routes.rb
  map.resources :groups, :controller => 'admin/groups',
:name_prefix => "admin_",
:path_prefix => "admin"


any ideas? the groups_url(id) is the only route that is failing in the test.

thanks :)

-- 
http://rubygeek.com - my blog featuring: Ruby, PHP and Perl
http://DevChix.com - boys can't have all the fun
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Re: [rspec-users] failing test with nested controller routes

2007-10-27 Thread Andy Watts 

Your routes.rb looks funky.  Are you running edge rails?  
It's worthwhile if you're set on restful stuff.
I don't think the name_prefix and path_prefix stuff is really necessary.

My nested routes read more like
  map.resources :groups
groups.resources :admins
  end

'rake routes > /tmp/routes' is really useful when working out routing
issues. 
If you're still learning restful routes, grab a copy of the beast forum
source code.
There's a model diagram somewhere on flickr also.
That was a huge help when I was getting my head around nested routes.

- Andy



Nola Stowe-5 wrote:
> 
> I have googled and browsed through spec-users archives, but didn't
> find anything different.
> 
> I used rspec scaffold command to generate a mvc for groups, I used
> nested controller so I could have a separate interface for admin.
> 
> the specs are the same as generated, so I won't post the whole thing.
> I did put the  nested routes names on the calls to the name routes:
> 
>   it "should redirect to the new group on successful save" do
> post_with_successful_save
> response.should redirect_to(admin_group_url("1"))
>   end
> 
> the error:
> 1)
> 'Admin::GroupsController handling POST /admin/groups should redirect to
> the new
> group on successful save' FAILED
> expected redirect to "http://test.host/admin/groups/1";, got redirect to
> "http://
> test.host/groups/1"
> ./spec/controllers/admin/groups_controller_spec.rb:246:
> 
> 
> 
> test log:
> 
> Processing GroupsController#update (for 0.0.0.0 at 2007-10-27 21:53:44)
> [PUT]
>   Session ID:
>   Parameters: {"action"=>"update", "id"=>"1",
> "controller"=>"admin/groups"}
> Redirected to http://test.host/groups/1
> Completed in 0.00061 (1647 reqs/sec) | DB: 0.0 (0%) | 302 Found
> [http://test.host/admin/groups/1]
> 
> it get redirected to http://test.host/groups/1 instead of admin/groups/1
> 
> It does work in the interface, which makes me believe that its not in
> rails but something in rspec:
> dev log:
> 
> Processing GroupsController#create (for 127.0.0.1 at 2007-10-27 22:04:00)
> [POST]
>   Session ID: 082b2f0103579493d5aa2a2851b4e721
>   Parameters: {"commit"=>"Create", "action"=>"create",
> "controller"=>"admin/groups", "group"=>{...}}
>   SQL (0.000337)   INSERT INTO groups (...)
> Redirected to http://127.0.0.1:3000/admin/groups/4
> Completed in 0.02443 (40 reqs/sec) | DB: 0.00034 (1%) | 302 Found
> [http://127.0.0.1/admin/groups]
> 
> it works... so the route works.. but not in the test?
> 
> here's whats in my routes.rb
>   map.resources :groups, :controller => 'admin/groups',
> :name_prefix => "admin_",
> :path_prefix => "admin"
> 
> 
> any ideas? the groups_url(id) is the only route that is failing in the
> test.
> 
> thanks :)
> 
> -- 
> http://rubygeek.com - my blog featuring: Ruby, PHP and Perl
> http://DevChix.com - boys can't have all the fun
> ___
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
> 
> 

-- 
View this message in context: 
http://www.nabble.com/failing-test-with-nested-controller-routes-tf4705370.html#a13450365
Sent from the rspec-users mailing list archive at Nabble.com.

___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users