similar to: Mocks? Really?

... is there a way to do this? We have some REST-ish POSTs we''d like to spec out. In the controller this gets accessed with request.raw_post.to_s, is there a way to set this with rspec? Thanks as always, Francis

Once again, here''s something I haven''t figured out. Apologies if this is too newb-ish, but, how do I spec my routes using RSpec-Rails? In particular, I''ve got a catch-all route that needs to catch a wide variety of URLs: map.document ''*url'', :controller => ''documents'', :action => ''show'' Is there a way to

Hello fellow RSpec users. Before you all start warming up your flame throwers please let me explain my Subject line. I''ve been working over 4 months on a large Rails project with a few other developers. Test coverage was spotty at best, though they *were* RSpec tests. One of the other developers and I had started adding more tests, mostly controller tests using the methodology

Given this code (which renders rjs), I''m faced with the fixture- driven way of spec-ing or mocking. How the heck to you mock this so the code at line (2) and (4) work right? I''m still struggling with mocks but it seems like this can be done. Forgive the naivety of this question. 1. def change_quantity 2. @line_item = LineItem.find_by_id(params[:id]) 3. unless

Hi all, I''m just starting to work w/ RSpec, so I hope this question isn''t too obvious or missing the point somehow: Is there a way in RSpec to specify that a controller action should use a specific HTTP status code? Specifically I want to test for the usage of 301 as opposed to 302, for a permanent redirection. response.should be_redirect looks like it calls

Hey all, I''m seeing a strange behavior in my spec that I can''t account for. I''ve got a route that looks like this: map.writing \ ''/writing'', :controller => ''abstracts'', :action => ''index'', :index => { :select => ''all'' } and I have template code that looks like this: <br

Hi! I know you must be answering a lot of basic questions, sorry about that :-) However I have not get it, how do you keep mocks updated without pain? I reached to the point where mocking things for view. I spec model-controller-view using "correct doc" way mocking-stubbing (plus I should run integration test to be sure that everything really works together). Now, when I want to

Just started looking at the Story Runner integration, and am converting a few Rails integration tests to get a feel for it. My integration tests relied on fixtures, and since my models have a significant amount of validation (and hence need valid data unless I save without validation), this has made setup easy. With stories however, I''m wondering what the recommended approach is.

What is the general opinion about fixtures versus mocking and stubbing in model specs? I heard from agile on IRC that they save the database testing for integration testing, but I also see that the caboose sample applicaiton uses fixtures. I also noticed that on the rspec site, it says "Ironically (for the traditional TDD''er) these are the only specs that we feel should actually

Suppose we have a method ''foo'' which internally uses another method ''bar''. Being good BDDers we mock out the ''bar'' method. After all, we only want to spec the ''foo'' method - actually running the ''bar'' method means slower, less maintainable and brittler specs. That''s why we <3 mocking,

Hi all ! I just started writing specs on a new project. I would just like to validate that this is the way you would write it. I know about mocks, stubs and expectations. I don''t think this is a problem for me. My question really boils down to: def index @projects = current_user.projects.active end My spec needs to return the proxy, no ? Here''s my code: context "A

hypothetical question for all you BDD experts: I want to make sure that a :list action always returns widgets in alphabetical order. There''s at least 2 ways of doing this: it "should fetch items in alphabetical order" do Widget.should_receive(:find).with(:order => "name ASC") get :list end it "should fetch items in alphabetical order" do [:red,

Hi! I''m developing a rails applicaton with specify-before approach, with nice results so far. I use mocks and stubs in both Controller and views tests, but the main issue is with model testing. Since I''ve seen many examples here and there, I don''t know if the right way is to use fixtures or not at all (in model specs). Atm, I''m using them, but I

Hi, I''m trying to setup a mock for my controller test but I can''t get it to recognise the mock. I use it "should find all users" do User.should_receive(:find).with( :all, :limit => 10 ).and_return([@user]) do_get end and in the controller @users = User.find(:all, :limit => 10 ) But this does not work. It gives me User expected :find with (:all)

My specs are still taking to long to run in a rails app. Is anyone using an in-memory database to run their specs? Any pointers or tips? Scott

Hey all, Here''s a question for everyone: how do you keep your mocks and stubs consistent with your real objects? I''m dipping my toes into the RSpec world, and it''s absolutely delightful (running dozens of tests in less than a second is nice as well), but I''m concerned about my ability to keep the mocks in my specs consistent with the behavior of their

Just wanted to pick some smart people about this topic: What are you guys doing to increase the speed of your specs? I''m a big fan of autotest, but right now my current project has 438 specs (for rails). Most of them are in the model, and for all of them we are hitting the database (they are more functional specs than unit-tests). The whole suite takes 112 seconds (meaning the

I saw in one of Dave C.''s comments to a ticket that "our current plan is to deprecate the mocking framework." I hadn''t heard anything about that, but then again I haven''t paid super close attention to the list. Are we planning on dumping the mock framework in favor of using Mocha (or any other framework one might want to plug in?). Pat

Hey all - The trunk currently supports three types of mocking/stubbing: Mock Objects (created dynamically at runtime) Partial Mocking of methods on existing classes Stubbing of methods on existing objects or classes The main difference between Partial Mocking and Stubbing is that Stubs don''t verify. I''m wondering if we really need the stubbing facility at all, given that we

So I''ve just started working on a rails project which currently has something like 7500 LOC. All of the tests are written in Test::Unit, although the test coverage is pretty poor: rcov says that 25% of the code is covered, while rake stats shows the code to test ratio as 1:0.1 (800 lines of test code). I guess I''m wondering what would generally be advisable here. Is it