Working in Sinatra, a local object request is created and made available to all views and helpers. So, I can make an ApplicationHelper module with helper methods, and if the helper methods are called in the view they can in turn call the request object, like so:
module ApplicationHelper
def nav_link_to(text,path)
path == request.path_info ? klass = 'class="current"' : klass = ''
%Q|<a href="#{path}" #{klass}>#{text}</a>|
end
end
Now, I want to test this, but in my test the request object doesn't exist. I tried to mock it, but that didn't work. Here's my test so far:
require 'minitest_helper'
require 'helpers/application_helper'
describe ApplicationHelper do
before :all do
#helper = Object.new
#helper.extend(ApplicationHelper)
end
describe "nav links" do
before :each do
request = MiniTest::Mock.new
request.expect :path_info, '/'
end
it "should return a link to a path" do
#helper.nav_link_to('test','/test').must_equal 'test'
end
it "should return an anchor link to the current path with class 'current'" do
#helper.nav_link_to('test','/').must_equal 'test'
end
end
end
So, how can you mock a 'local' object so that the code your testing can call it?
You need to make sure there is a request method on your #helper object that returns the mock request object.
In RSpec I'd just stub it. I'm not particularly familiar with Minitest, but a quick look suggests that this might work in recent versions (if you change request to #request in your before :each):
it "should return a link to a path" do
#helper.stub :request, #request do
#helper.nav_link_to('test','/test').must_equal 'test'
end
end
Update
Since Minitest requires that the stubbed method is already defined on the object, you could make #helper an instance of Struct.new(:request) instead of Object, i.e.
#helper = Struct.new(:request).new
And actually, having done that, you might not need the stub at all! You could just do
before :each do
#helper.request = MiniTest::Mock.new
#helper.request.expect :path_info, '/'
end
Related
I want to test a following method, which calls a module method with a block.
def test_target
MyModule.send do |payload|
payload.my_text = "payload text"
end
end
MyModule's structure is like following.
module MyModule
class Payload
attr_accessor :my_text
def send
# do things with my_text
end
end
class << self
def send
payload = Payload.new
yield payload
payload.send
end
end
How can I test whether MyModule receives send method with a block, which assigns "payload text" to payload.my_text?
Currently I'm only testing expect(MyModule).to receive(:send).once. I looked through and tried Rspec yield matchers but cannot get things done. (Maybe I've ben searching for wrong keywords..)
The easiest way is to insert a double as the yield argument, which you can make an assertion on.
payload = Payload.new
allow(Payload).to receive(:new).and_return(payload)
test_target
expect(payload.my_text).to eq 'payload text'
Alternatively you could also use expect_any_instance_of, but I'd always prefer to use a specific double instead.
I would mock MyModule to yield another mock, that would allow speccing that my_text= is called on the yielded object.
let(:payload) { instance_double('Payload') }
before do
allow(MyModule).to receive(:send).and_yield(payload)
allow(payload).to receive(:my_text=).and_return(nil)
end
# expectations
expect(MyModule).to have_received(:send).once
expect(payload).to have_received(:my_text=).with('payload text').once
First, for the short version:
Isn't a method definition just a block? Why can't I do something like:
obj.instance_exec(&other_obj.method(:my_method))
with the goal of running some module method in the context of an instance of a separate class? The method is called, but it doesn't seem to be executed in the context of 'obj', despite the 'instance_exec' call.
The only way I can figure out how to accomplish this is to wrap all of the code of 'my_method' in a proc, then call in the following manner instead:
obj.instance_eval(&other_obj.my_method)
but I'd like to avoid encapsulating all of my module methods in procs.
Now, for the long version:
I'm attempting to create a modularized external provider system, where for any given class/method (generally controller methods,) I can call a corresponding method for a given provider (e.g. facebook).
Since there could be multiple providers, the provider methods need to be namespaced, but instead of simply including a bunch of methods like, for example, 'facebook_invitation_create', I'd like my InvitationsController instance to have a facebook member containing a create method - e.g.
class InvitationsController < ApplicationController
def create
...
# e.g. self.facebook.create
self.send(params[:provider]).create
...
end
end
Furthermore, I'd like the provider methods to not only function as if they were part of the controller itself - meaning they should have access to things like controller instance variables, params, session, etc. - but also to be (mostly) written as if they were part of the controller itself - meaning without any complex additional code as a result of being modularized.
I've created a simplified example below, in which MyClass has a greet method, which if called with a valid provider name (:facebook in this case), will call that providers greet method instead. In turn, the provider greet method accesses the message method of the including class, as if it were part of the class itself.
module Providers
def facebook
#facebook ||= FacebookProvider
end
module FacebookProvider
class << self
def greet
proc {
"#{message} from facebook!"
}
end
end
end
end
class MyClass
include Providers
attr_accessor :message
def initialize(message="hello")
self.message = message
end
def greet(provider=nil)
(provider.nil? or !self.respond_to?(provider)) ? message : instance_exec(&self.send(provider).greet)
end
end
This actually accomplishes almost everything I've previously stated, but I'm hung up on the fact that my provider functions need to be encapsulated in procs. I thought maybe I could simply call instance_exec on the method instead (after removing the proc encapsulation):
instance_exec(&self.send(provider).method(:greet))
...but then it seems like the instance_exec is ignored, as I get the error:
NameError: undefined local variable or method `message' for Providers::FacebookProvider:Module
Is there any way to call instance_exec on a defined method?
(I'm open to suggestions on how to better implement this as well...)
I think this is simpler than you might expect (and I realize that my answer is 2 years after you asked)
You can use instance methods from modules and bind them to any object.
module Providers
def facebook
#facebook ||= FacebookProvider
end
module FacebookProvider
def greet
"#{message} from facebook!"
end
end
end
class MyClass
include Providers
attr_accessor :message
def initialize(message="hello")
self.message = message
end
def greet(provider=nil)
if provider
provider.instance_method(:greet).bind(self).call
else
message
end
end
end
If your provider is a module, you can user instance_method to create an UnboundMethod and bind it to the current self.
This is delegation.
It's the basis for the casting gem which would work like this:
delegate(:greet, provider)
Or, if you opt-in to using method_missing from casting, your code could just look like this:
greet
But you'd need to set your delegate first:
class MyClass
include Providers
include Casting::Client
delegate_missing_methods
attr_accessor :message
def initialize(message="hello", provider=facebook)
cast_as(provider)
self.message = message
end
end
MyClass.new.greet # => "hello from facebook!"
I wrote about what delegation is and is not on my blog which is relevant to understanding DCI and what I wrote about in Clean Ruby
Maybe I'm not following along, but it seems like you are making this harder than it needs to be.
Why not implement a "dispatch" pattern in your class, where you have a hash of provider names and provider methods {:facebook=>"facebook_greet"} and then just "send" the incoming call to the correct handler via "Object#send" (http://ruby-doc.org/core-1.9.3/Object.html#method-i-send)? Send is very fast for dispatching methods, so unlike eval, you should get great performance.
Here's some code to demonstrate the way I'd solve it (assuming I am following along with what you're trying to accomplish):
module TwitterProvider
def providerInit(providers)
#providers[:twitter]="twitter_greet"
super(providers) if defined?(super)
end
def twitter_greet
"Hello Twitter User"
end
end
module FacebookProvider
def providerInit(providers)
providers[:facebook]="facebook_greet"
super(providers) if defined?(super)
end
def facebook_greet
"Hello Facebook User"
end
end
class MyClass
include FacebookProvider
include TwitterProvider
attr_accessor :message
def providerInit(providers)
super(providers) if defined?(super)
end
def initialize(message="hello")
#providers = {}
self.message = message
providerInit(#providers)
end
def greet(provider=nil)
if provider.nil? or !self.respond_to?(#providers[provider])
self.message
else
self.send(#providers[provider])
end
end
end
my_class = MyClass.new
puts my_class.greet
puts my_class.greet(:twitter)
puts my_class.greet(:facebook)
# Output:
# hello
# Hello Twitter User
# Hello Facebook User
I want to test whether a function invokes other functions properly with minitest Ruby, but I cannot find a proper assert to test from the doc.
The source code
class SomeClass
def invoke_function(name)
name == "right" ? right () : wrong ()
end
def right
#...
end
def wrong
#...
end
end
The test code:
describe SomeClass do
it "should invoke right function" do
# assert right() is called
end
it "should invoke other function" do
# assert wrong() is called
end
end
Minitest has a special .expect :call for checking if some method is called.
describe SomeClass do
it "should invoke right function" do
mocked_method = MiniTest::Mock.new
mocked_method.expect :call, return_value, []
some_instance = SomeClass.new
some_instance.stub :right, mocked_method do
some_instance.invoke_function("right")
end
mocked_method.verify
end
end
Unfortunately this feature is not documented very well. I found about it from here: https://github.com/seattlerb/minitest/issues/216
With minitest you use expect method to set the expectation for a method to be called on a mock object like so
obj = MiniTest::Mock.new
obj.expect :right
If you want to set expectation with parameters and return values then:
obj.expect :right, return_value, parameters
And for the concrete object like so:
obj = SomeClass.new
assert_send([obj, :right, *parameters])
According to the given example, there is no other delegate class, and you want to make sure the method is called properly from the same class. Then below code snippet should work:
class SomeTest < Minitest::Test
def setup
#obj = SomeClass.new
end
def test_right_method_is_called
#obj.stub :right, true do
#obj.stub :wrong, false do
assert(#obj.invoke_function('right'))
end
end
end
def test_wrong_method_is_called
#obj.stub :right, false do
#obj.stub :wrong, true do
assert(#obj.invoke_function('other'))
end
end
end
end
The idea is to stub [method_expect_to_be_called] by returning a simple true value, and in the stub block assert it's indeed being called and returning the true value. To stub the other unexpected method is just to make sure that it's not being called.
Note: assert_send won't work correctly. Please refer to official doc.
In fact, below statement will pass, but doesn't mean it's working as expected:
assert_send([obj, :invoke_function, 'right'])
# it's just calling invoke_function method, but not verifying any method is being called
To stub and assert method calls, you use MiniTest::Mock. There are 2 ways to use this:
stub an object's method to return a mock object, which has a stubbed method
stub an object's method to call the mock method
test "return the mock object when calling the stubbed method" do
# the object you want to stub
obj = Book.new
mock = MiniTest::Mock.new
mock.expect :the_method_to_stub, "my cool return value"
obj.stub :method_that_gives_you_a_mock, mock do
x = obj.method_that_gives_you_a_mock
assert_equal x.the_method_to_stub, "my cool return value"
end
# assert that the method was called once
mock.verify
end
test "call the mock method when calling the stubbed method" do
# the object you want to stub
obj = Book.new
mock = MiniTest::Mock.new
# use :call to make the mock a callable
mock.expect :call, "my cool return value"
obj.stub :method_that_calls_the_mock, mock do
assert_equal obj.method_that_calls_the_mock, "my cool return value"
end
# assert that the method was called once
mock.verify
end
To use MiniTest::Mock, you may need to add require 'minitest/autorun' to load the MiniTest constants.
Recently I've created a gem for easing this kind of assertions called 'stubberry'.
Here how you can manage the needed behaviour using it.
First you need to answer the questions:
do you have an access to the original object before the test sequence
execution?
is there any indirect way you can sure call happened? i.e. there should be some methods invocations on some other object you have access to.
do you need the method to be actually called or could it be stubbed with the prooper object or callable?
If you have access to the object, and you can stub the method, with your callable:
obj.stub_must( :right, -> { stub_response } ) {
... do something
}
If you have access to the object but you don't want to stub the method and you just want to ensure that method was invoked:
assert_method_called( obj, :right ) {
.... do something with obj
}
If you don't have the access to the object you want to test against.
But you can do indirect check with some other object method invocation, Lets say 'right' method will end with API call execution:
API.stub_must( :get, -> (path, params) {
assert_equal( path, :expected_path )
assert_equal( params, {} )
} ) do
... do something
end
If you can't do an indirect check:
stunt_boudle = Obj.new
stunt_boudle.stub_must( :right, -> () {
#do needed assertions
} ) do
Obj.stub_must(:new, stunt_boudle) do
# do some integration testing
end
end
# OR use assert_method_called the same way
Also there is a cool set of stubbing ActiveRecord object by id, you can use them in this case when you can't have access to the object at the start of the testing actions and its an ActiveRecord object.
Is it possible to have HTTParty deserialize the results from a GET to a strongly typed ruby object? For example
class Myclass
include HTTParty
end
x = Myclass.get('http://api.stackoverflow.com/1.0/questions?tags=HTTParty')
puts x.total
puts x.questions[0].title
Right now it deserializes it into a hash
puts x["total"]
My question is actually if HTTParty supports this OTB, not by installing additional gems.
Edit:
I'm still new to Ruby, but I recall that class fields are all private so they would need to be accessed through getter/setter methods. So maybe this question isn't a valid one?
If you are just wanting method syntax, you can use an open struct.
require 'httparty'
require 'ostruct'
result = HTTParty.get 'http://api.stackoverflow.com/1.0/questions?tags=HTTParty'
object = OpenStruct.new result
object.total # => 2634237
A possible downside is that this object is totally open such that if you invoke a nonexistent method on it, it will just return nil (if you invoke a setter, it will create both the setter and getter)
It sounds like you want the return value of Myclass::get to be an instance of Myclass. If that's the case, you could cache the return value from the HTTP request and implement method_missing to return values from that hash:
class Myclass
include HTTParty
attr_accessor :retrieved_values
def method_missing(method, *args, &block)
if retrieved_values.key?(method)
retrieved_values[method]
else
super
end
end
def self.get_with_massaging(url)
new.tap do |instance|
instance.retrieved_values = get_without_massaging(url)
end
end
class << self
alias_method :get_without_massaging, :get
alias_method :get, :get_with_massaging
end
end
This isn't exactly what you asked for, because it only works one level deep — i.e., x.questions[0].title would need to be x.questions[0][:title]
x = Myclass.get('http://api.stackoverflow.com/1.0/questions?tags=HTTParty')
p x.total
p x.questions[0][:title]
Perhaps you could come up with some hybrid of this answer and Joshua Creek's to take advantage of OpenStruct.
I should also point out that all the method aliasing trickery isn't necessary if your method doesn't have to be named get.
#rubiii has previously shown (Savon soap body problem) that you can customize Savon requests with
class SomeXML
def self.to_s
"<some>xml</some>"
end
end
client.request :some_action do
soap.body = SomeXML
end
But why would you use a class method like this? It would seem more likely that you would ask an instance of a class to turn itself into a hash for the request body. i.e.
#instance = SomeClass.new
client.request :some_action do
soap.body = #instance.to_soap
end
However, when I try doing this, #instance variable isn't in 'scope' within the request block. So I get a can't call method to_soap on nil. But if instead I use a class method then I can get it to work. i.e.
class SomeClass
##soap_hash = nil
def self.soap_hash=(hash)
##soap_hash = hash
end
def self.soap_hash
##soap_hash
end
end
SomeClass.soap_hash = #instance.to_soap
client.request :some_action do
soap.body = SomeClass.soap_hash
end
I don't get it?
The class-method example was just that, an example. Feel free to use any object that responds to to_s.
The block is processed via instance_eval with delegation, which is why you can only use local variables and methods inside the block. If you need to use instance variables, change your block to accept arguments. Savon will notice that you specified arguments and yield those values instead of evaluating the block.
For information about which arguments to specifiy and everything else, please RTFM ;)