Every repository with this icon (
) is private.
Every repository with this icon (
) is public.
| Description: | RR (Double Ruby) is a test double framework that features a rich selection of double techniques and a terse syntax. edit |
-
0 votes
RR omits "unexpected method invocation" when stub exists
1 comment Created 6 months ago by trogdoroIf I have "mock(A).b(2)" and "A.b(3)" is invoked instead, RR clues me in on this by listing "b(3)" under "unexpected method invocation", which is great. However, if I also have stub(A).b it doesn't. It could be argued that the "b(3)" call is no longer unexpected given the stub, but it would be helpful to provide a clue that b(3) was called instead of b(2), lest the developer be left on his own to track this down. Mocking one invocation to a method and stubbing out the rest seems like a common use case.
Comments
-
0 votes
RR omits "unexpected method invocation" when exceptions are caught
1 comment Created 6 months ago by trogdoroIf I have "mock(A).b(2)" and "A.b(3)" is invoked instead, RR clues me in on this by listing "b(3)" under "unexpected method invocation". However, if the code being tested has "rescue nil" after the line being stubbed, it doesn't. It appears from this that RR relies on your code allowing exceptions to float up to the top. RSpec must have another mechanism, since it was able to handle the same code (reporting the invalid call).
Comments
-
0 votes
stub.instance_of doesn't stub existing instances' methods
3 comments Created 3 months ago by calebWhen I use stub.instance_of, instances created before I create the stub do not have their methods stubbed. For example:
require 'rr' include RR::Adapters::RRMethods class MyClass def m "not stubbed" end end i1 = MyClass.new stub.instance_of(MyClass).m { "stubbed" } i2 = MyClass.new puts "i1.m is " + i1.m puts "i2.m is " + i2.mWhen I run this, I get:
~/Desktop% ruby rr_test.rb i1.m is not stubbed i2.m is stubbedComments
There is a difference between RR and Mocha here.
Mocha will redefine the method on the class, while RR stubs MyClass.new.
I'll take a look into coming to some resolution here. There will probably be two ways of using instance_of, for each behavior.Okay, that makes sense. I was expecting a Mocha-like behavior, but that's because I've used Mocha in the past. It's like there should be two methods:
stub.any_instance_of(MyClass)and
stub.new_instances_of(MyClass)Thanks for the clarification, it was easy enough to write my tests to work with rr's behavior.
-
2 votes
undefined method deliver_* for class Class when mocking ActionMailer classes
4 comments Created 3 months ago by btakitaHi,
I'm using rr, and trying to mock(Notifier) in a rails app. When I do this using Mocha it works fine:
Notifier.expects(:deliver_password_reset_instructions).with(user)
However, if I do this using rr:
mock(Notifier).deliver_password_reset_instructions(user)
I get the error:
undefined method deliver_password_reset_instructions' for classClass'
I think the deliver_password_reset_instructions method is handled by a method_missing of rails ActionMailer::Base class, which would then call the method +password_reset_instructions+ on the Notifier class.
Any insights into this? Any suggestion how to mock this?
Cheers,
LawrenceComments
lawrencepit
Sun Aug 23 15:19:34 -0700 2009
| link
The complete stacktrace:
1) NameError in 'User should deliver password reset instructions' undefined method `deliver_password_reset_instructions' for class `Class' /usr/local/lib/ruby/gems/1.8/gems/rr-0.10.0/lib/rr/double_injection.rb:15:in `alias_method' /usr/local/lib/ruby/gems/1.8/gems/rr-0.10.0/lib/rr/double_injection.rb:15:in `__send__' /usr/local/lib/ruby/gems/1.8/gems/rr-0.10.0/lib/rr/double_injection.rb:15:in `initialize' /usr/local/lib/ruby/gems/1.8/gems/rr-0.10.0/lib/rr/space.rb:37:in `new' /usr/local/lib/ruby/gems/1.8/gems/rr-0.10.0/lib/rr/space.rb:37:in `double_injection' /usr/local/lib/ruby/gems/1.8/gems/rr-0.10.0/lib/rr/double_definitions/strategies/scope/instance.rb:8:in `do_call' /usr/local/lib/ruby/gems/1.8/gems/rr-0.10.0/lib/rr/double_definitions/strategies/strategy.rb:37:in `call' /usr/local/lib/ruby/gems/1.8/gems/rr-0.10.0/lib/rr/double_definitions/double_definition_creator.rb:157:in `create' /usr/local/lib/ruby/gems/1.8/gems/rr-0.10.0/lib/rr/double_definitions/double_definition_creator_proxy.rb:29:in `method_missing' ./spec/models/user_spec.rb:19: /usr/local/lib/ruby/gems/1.8/gems/rspec-1.2.6/lib/spec/example/example_methods.rb:40:in `instance_eval' /usr/local/lib/ruby/gems/1.8/gems/rspec-1.2.6/lib/spec/example/example_methods.rb:40:in `execute' /usr/local/lib/ruby/1.8/timeout.rb:48:in `timeout' /usr/local/lib/ruby/gems/1.8/gems/rspec-1.2.6/lib/spec/example/example_methods.rb:37:in `execute' /usr/local/lib/ruby/gems/1.8/gems/rspec-1.2.6/lib/spec/example/example_group_methods.rb:207:in `run_examples' /usr/local/lib/ruby/gems/1.8/gems/rspec-1.2.6/lib/spec/example/example_group_methods.rb:205:in `each' /usr/local/lib/ruby/gems/1.8/gems/rspec-1.2.6/lib/spec/example/example_group_methods.rb:205:in `run_examples' /usr/local/lib/ruby/gems/1.8/gems/rspec-1.2.6/lib/spec/example/example_group_methods.rb:103:in `run' /usr/local/lib/ruby/gems/1.8/gems/rspec-1.2.6/lib/spec/runner/example_group_runner.rb:23:in `run' /usr/local/lib/ruby/gems/1.8/gems/rspec-1.2.6/lib/spec/runner/example_group_runner.rb:22:in `each' /usr/local/lib/ruby/gems/1.8/gems/rspec-1.2.6/lib/spec/runner/example_group_runner.rb:22:in `run' /usr/local/lib/ruby/gems/1.8/gems/rspec-1.2.6/lib/spec/runner/options.rb:119:in `run_examples' /usr/local/lib/ruby/gems/1.8/gems/rspec-1.2.6/lib/spec/runner/command_line.rb:9:in `run' /usr/local/lib/ruby/gems/1.8/gems/rspec-1.2.6/bin/spec:4: /usr/local/bin/spec:19:in `load' /usr/local/bin/spec:19:
lawrencepit
Thu Sep 03 18:30:37 -0700 2009
| link
http://technicalpickles.com/posts/ruby-stubbing-and-mocking-with-rr
In the last paragraph titled "gotchas" the author of this post mentions a workaround.
lawrencepit
Sun Oct 18 23:15:56 -0700 2009
| link
Yes, it is! Thanks a lot.
-
DoubleInjections have issues on private methods.
Comments
-
0 votes
mocking view template expecting call to render fails
2 comments Created 2 months ago by lawrencepitUsing rails 2.3.3 and rspec 1.2.6, my view is simply this:
= render :partial => "layouts/resources"My rspec test looks like this:
require File.expand_path(File.dirname(__FILE__) + '/../../spec_helper') describe "/holidays/index.html.haml" do it "should render the resources layout partial" do # RSpec: works #template.should_receive(:render).with(:partial => "layouts/resources") # Mocha: fails #template.expects(:render).with(:partial => "layouts/resources") # RR: fails mock(template).render(:partial => "layouts/resources") render "/holidays/index.html.haml" end endWhich results in:
On subject #<ActionView::Base:0x304b4bc>, unexpected method invocation: render({:locals=>{}, :layout=>nil, :file=>"holidays/index.html.haml"}) expected invocations: - render({:partial=>"layouts/resources"})Any advice?
Comments
It looks like there are multiple calls to render.
Try:
stub(template).render.verbose
mock(template).render(:partial => "layouts/resources")
lawrencepit
Sun Oct 18 23:22:51 -0700 2009
| link
The output I get is then:
render({:layout=>nil, :file=>"holidays/index.html.haml", :locals=>{}}) should render the resources layout partial render({:partial=>"layouts/resources"}) Called 0 times. Expected 1 times. -
0 votes
config.mock_with :rr vs config.mock_with RR::Adapters::Rspec
2 comments Created 2 months ago by lawrencepitFrom the readme I was testing this with rspec 1.2.6:
subject = Object.new stub(subject).foo subject.foo(1) subject.should have_received.foo(1) subject.should have_received.bar # this failsdidn't work for me. I had config.mock_with :rr, turns out it needs to be config.mock_with RR::Adapters::Rspec.
I would make the latter the default in the readme. With the latest versions of rspec and rr using the :rr symbol doesn't work as well.
Comments
this should probably be fixed on the rspec side. rspec/lib/spec/adapters/mock_frameworks/rr.rb hasn't been updated for months.
lawrencepit
Tue Oct 13 21:51:40 -0700 2009
| link
-
1 vote
I've got this:
@user = User.make # Machinist stub(User).find_by_account_name(@user.account_name) { @user }I get an error when User.find_by_account_name(@user.account_name) is called elsewhere:
NameError: undefined local variable or method `implementation' for #<RR::MethodDispatches::MethodMissingDispatchComments
contentfree
Fri Sep 18 16:58:35 -0700 2009
| link
This obviously breaks everything.
I'm using the latest from Github (9ce71c13) as of today.
-
require File.expand_path("#{File.dirname(__FILE__)}/../spec_helper") class Foo def method_a return "a" end def method_b return "b" end end describe Foo do it "should be callable twice with different methods" do stub.instance_of(Foo).method_a {"Q"} stub.instance_of(Foo).method_b {"R"} Foo.new.method_a.should == "Q" Foo.new.method_b.should == "R" end endComments
-
0 votes
rr freezes when stubbing a mailer call
2 comments Created about 1 month ago by bommaritobrianmatthewI have the following code in my before block (UserMailer is an ActionMailer):
before do
stub(UserMailer).deliver_confirmation_email stub(User).new { @user }end
In one of my expectations I do this:
UserMailer.should have_received.deliver_confirmation_email
Whenever rake spec or autospec hits that expectation (I have commented it and that solves this issue) it just freezes.
I don't know whether this is a known issue, or if rr doesn't like mailers for some reason. I am using rSpec 1.2.9 and rr 0.10.4
Comments
That is strange.
Can you print the contents and/or length of RR::Space.instance.recorded_calls?
Thanks,
Brian
bommaritobrianmatthew
Mon Oct 19 07:33:53 -0700 2009
| link
I have a couple of more bits of info that might be helpful for this:
I finally got it working, but i have to mock out the call in the one expectation that checks for it, and then stub it in the before(:each) block and it works fine. I also noticed similar behavior when I tried stubbing a #new on an instance variable, and when I checked for the call on the actual model. No errors, just a freeze up.
What would be the best way to grab the contents of recorded_calls since it will freeze before being able to run that code?
-
Greetings.
I'm using JRuby 1.4.0 and noticed the following warnings when running some specs this morning:
/foo/bar/baz/vendor/gems/rr-0.10.4/lib/rr/spy_verification_proxy.rb:5 warning: `class_eval' should not be aliasedand similarly...
/foo/bar/baz/vendor/gems/rr-0.10.4/lib/rr/double_definitions/double_definition_creator_proxy.rb:8 warning: `class_eval' should not be aliasedIt'd be nice not to see these warnings every time I run my specs.
Comments
Perhaps this approach would be sufficient:
module RR class SpyVerificationProxy BANNED_METHODS = %w[object_id instance_eval instace_exec respond_to class_eval] instance_methods.each do |m| unless m =~ /^_/ || BANNED_METHODS.include?(m.to_s) alias_method "__blank_slated_#{m}", m undef_method m end end def initialize(subject) @subject = subject end def method_missing(method_name, *args, &block) SpyVerification.new(@subject, method_name, args) end end endDitto for DoubleDefinitionCreatorProxy.
-
The following test-case passes without an error:
obj = Object.new stub(obj).method dont_allow(obj).method obj.methodI expect TimesCalledError.
Comments
phildarnowsky
Wed Nov 25 13:11:20 -0800 2009
| link
I've noticed the same. This is a workaround that is ugly but works, i.e. raises an error:
obj = Object.new stub(obj).method stub(obj).method {raise TimesCalledError} obj.method -
1 vote
stub method with return value doesn't work in ruby 1.9.1
0 comments Created 14 days ago by aberantthis example works in ruby 1.8.6, 1.8.7, but breaks in 1.9.1
require 'rubygems'
require 'spec'
require 'rr'
include RR::Adapters::Rspecmock( socket = Object.new )
stub(socket).bind("", 3333)stub(UDPSocket).new { socket }
UDPSocket.new.bind( "", 3333 )
UDPSocket.new.bind( "", 3333 )Comments
-
0 votes
stub.instance_of doesn't work with records created with allocate
0 comments Created 12 days ago by jpalermoThis makes any active record mocking really verbose. Instead of being able to do stub.instance_of(User).my_method I have to stub.proxy the call to find and then stub the returned records myself.
Comments
-
It is an entirely common usage scenario to have multiple paths to a 'test_helper.rb' file.
For instance, say that I have tests in test/unit/something_special for organizational purposes. This is guaranteed to cause the same problem. I should know; I'm running into this now! Argh!
Comments
Thanks. I'll take a look at fixing this.