similar to: stubbing with and without a string

Mocha''s mock/stub framework has the ability to stub all methods on a mock given. Does RSpec''s mocking framework have this ability? And if not, is there some reason it shouldn''t be implemeneted? Regards, Scott

What is the appropriate way to stub out (and put an expectation on Object#__send__), without getting warnings from the Rspec mock library? Scott

Hello! I''m just a caveman with some caveman questions. I''ve been parsing Rspec for quite a while, and I''m writing my first series of specs. My initial impressions are "Verbose, but understandable. Helpful and intuitive, but so much to digest." I want to congratulate the folks who are dedicating a chunk of their lives to writing this, and ask 2 caveman

Hi all, Initially I thought this was a bug in the built-in mocking framework(and it still may be), but I better hash it out on the mailing list before I file/reopen the ticket: http://rspec.lighthouseapp.com/projects/5645/tickets/478-mocks-on-constants#ticket-478-6 I thought my example illustrated my problem, but obviously I was passing the wrong arguments to the mock. I revised my example to

Hello, As I''m becoming more and more familiar with mocking/stubbing, I''m going back to some of my model specs and revaluating how I wrote them. I have certain models in which validation requires the presence of an associated model, which itself needs to be valid(validates_presence_of and validates_associated). When I wrote the specs, I wrote helpers for the attributes instead

I have something like the following: def my_fun my_fun2 do raise Error end end I know that I can verify that the method receives my_fun2. How can I mock/stub out the example to verify that it calls raise Error? Scott

Is there any reason why a stub couldn''t both yield and return? I''m looking for a way to mock out a class I''ve made named "AnonymousClass": class AnonymousClass def initialize(&blk) @klass = Class.new @klass.instance_eval(&blk) if block_given? end def new @klass.new end def evaluate(&blk)

I''ve notice that a project like Rubinius has both a spec & a test directory. Rspec has only a spec directory. Obviously I support BDD, but isn''t there also a place for state based/verification testing? I sometimes sense that I *do* want to practice Test Driven Development. That is, I want some assurance that my production code will run as intended. But I also

Consider the following method: def name_to_terminal puts "Scott Taylor" end How would I spec this out? Scott

OK, so i''ve played a bit with mocks and mock_models in controller and view tests and i have a question. Is this statement really correct: "We highly recommend that you exploit the mock framework here rather than providing real model objects in order to keep the view specs isolated from changes to your models." (http://rspec.rubyforge.org/documentation/rails/writing/views.html

I have the following code, which yields instance eval''s the block given: class Foo def bar(&blk) instance_eval &blk end def baz yield end end The effect of this is that self is reassigned: Foo.new.bar do # here, self is the instance of Foo # created by new end But normally self is the object in which Foo.new.bar {...} occurs. Foo.new.baz do

I want to create a spec/regressions directory with various regressions (for my rails project). I tried the following: describe LoginController, "regression for user creation when steves_sister does not exist", :behavior_type => :controller do controller_name :login before :each do @params = { "commit"=>"Create Account",

Just ran svn up this morning, and got this (after running ./script/ generate rspec) escher: ./script/spec spec/models/item_spec.rb Finished in 8.0e-06 seconds 0 examples, 0 failures ./script/spec:4:in `run'': wrong number of arguments (3 for 1) (ArgumentError) from ./script/spec:4 Using rails 1.2.3, rspec trunk, on Mac OS X.4.9. Any ideas, or is this a bug in

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

Okay - so the sqlite bug reported a day or so ago on the list is real bug. I''m going to file something in the tracker for that... I also learned that before(:all)...after(:all) is not wrapped in a transaction, the way before(:each)...after(:each) is. Is there some reason behind this? Can you not wrap transactions inside transactions? Scott

As it is currently, in trunk, --failures and --examples except a text file, each line containing the name of a spec. I''m wondering: Would a a patch to use YAML (instead or as well as) plain text be welcomed? I''m thinking of a yaml file like the following: spec_file_1: file: spec/person_spec.rb specs: - should have first name - should provide email address

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

I''ve been seeing the following in some of my view specs: .P.P........ignoring 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</tr>\n\t<tr>\n\t\t<td>#<Spec::Mocks::Mock:0" text around close:

I am completely baffled by this one - My guess is that there is no pure ruby way to do this - but how could I set up a spec to test that one method is an alias of another? Thanks for any help, Scott

Test First Development is great...But should you use it when you are adding classes/methods on to external library that doesn''t have an extensive test suite? I noticed that the rspec plugin for autotest has no specs. David Chemlinsky said something to the list a while back that has been stewing in my subconscious - that you develop software differently using Test First