I'm writing a Rails app to send text messages using the Twilio API:
http://www.twilio.com/docs/api/rest/sending-sms
and to this end, I do:
client = Twilio::REST::Client.new account_sid, auth_token
client.account.sms.messages.create({
# stuff ...
})
That's all good and nice -- however, I don't want my tests to send a bunch of text messages because that would be stupid. So, I'd like to override Twilio::REST::Client.new to give me an object that'll let me call acccount.sms.messages.create in my tests without undue fuss.
I have a solution that works, but feels ugly:
def mock_twilio_service(stub_client)
Twilio::REST::Client.stub :new, stub_client do
yield
end
end
class Recordy
attr_accessor :calls
def initialize
#calls = []
end
def method_missing(method, *args)
ret = self.class.new
#calls << {
method: method,
args: args,
block_given: block_given?,
ret: ret
}
yield if block_given?
ret
end
end
and then in my test:
test "send a text" do
cli = Recordy.new
mock_twilio_service cli do
# ... stuff
end
end
I feel like I'm missing something Super Obvious, but I'm not sure. Am I? Or am I totally barking up the wrong tree? (Yes, I've looked at How do I mock a Class with Ruby? but I don't think it's quite the same...?)
Another idea would be to use WebMock. As your client is making requests to Twilio. You can just stub out the requests. Within the stub you can also define what is returned from the requests and with which parameters it can be called.
And when you set
WebMock.disable_net_connect!
it is sure that no real requests can be made from the test.
This way you don't change any behavior of your test and will not rely on an external API for your tests to pass.
Twilio evangelist here.
We wrote Test Credentials exactly for this scenario. Test Credentials are a special set of credentials (AccountSid and AuthToken) that you can use when you make requests to the Twilio REST API that tell it to basically just go through the motions of making a phone call or sending a text message, but not actually do it (or charge you for it).
You can also use a special set of phone numbers to get Twilio to return specific success or error conditions.
You can find your test credentials in your Twilio dashboard.
Hope that helps.
Related
I'm trying to figure out how to set the timezone on a per request basis in Sinatra for a multithreaded application.
Rails provides the :around_action filter to handle this wherein the request is processed inside of a Time.use_zone block.
around_action :set_time_zone, if: :current_user
def set_time_zone(&block)
Time.use_zone(current_user.time_zone, &block)
end
Sinatra, however, only provides before and after filters:
before do
Time.zone = current_user.time_zone
end
after do
Time.zone = default_time_zone
end
That approach, however, does not seem threadsafe. What is the right way to accomplish this in Sinatra?
I recall there being a Sinatra extension to provide around hooks, but can't find it. Otherwise, you'd have to put the code in each action:
def my_endpoint
with_around_hooks do
render text: "hello world"
end
end
private
def with_around_hooks(&blk)
# you could hypothetically put more stuff here
Time.use_zone(current_user.time_zone, &blk)
end
Hopefully someone else knows a way to wrap code around each request though
I'm updating an application that was working with a very old version of RSpec (2.9.0). It works fine with 3.8, but I get a deprecation error about the following code:
response = Net::HTTPOK.new(1.0, "200", "OK")
response.stub(:content_type => 'text/json', :body => contents_raw)
Now, this code is a mock callout to an external API, and it is deep inside my code's libraries. The application I'm testing is a Sinatra app, so I'm using "get" from Rack::Test::Methods to test my app, but then deep inside the app itself is this response.stub
Apparently I should be using "double()" and "allow(object).to receive(...)", but all the examples I've seen are for using double directly in your test's "it" block, which this code is nowhere near. If I actually try to use double I just get a no method error.
WebMocks seems like a very large hammer to just replace this single call.
Maybe the right thing to do is to make a superclass of Net::HTTPOK and pass the response data in wit that superclass's new?
Huh. OK, so the wrapper class method turned out to be far easier than I expected. In my spec file I added:
class HttpWrapper < Net::HTTPOK
def initialize(data, *args)
#data = data
super(*args)
end
def content_type
'text/json'
end
def body
#data
end
end
(Bizarre detail: if I replace every instance of "data" above with "body", it explodes horribly.)
And at the block of code in question I now have:
response = HttpWrapper.new(contents_raw, 1.0, "200", "OK")
And that seems to have done the trick just fine.
If this is a terrible idea for some reason, hopefully someone will let me know. :)
the best way to mock http, use gem which called iswebmock
I've crafted a basic TCP client using EventMachine. Code:
# run.rb
EventMachine::run do
EventMachine::connect $config_host, $config_port, Bot
end
# bot.rb
module Bot
def post_init
# log us in and do any other spinup.
sleep(1)
send_data $config_login + "\n"
EventMachine.add_periodic_timer($config_keepalive_duration) { send_data $config_keepalive_str + "\n" }
#valid_command = /^<#{$config_passphrase}:([^>:]+):(#\d+)>(.*)$/
end
def receive_data(data)
if(ma = #valid_command.match(data))
command, user, args = ma[1,3]
args.strip!
command.downcase!
p "Received: #{command}, #{user}, #{args}"
# and.. here we handle the command.
end
end
end
This all works quite well. The basic idea is that it should connect, listen for specially formatted commands, and execute the command; in executing the command, there may be any number of "actions" taken that result in various data sent by the client.
But, for my next trick, I need to add the ability to actually handle the commands that Bot receives.
I'd like to do this using a dynamic library of event listeners, or something similar to that; ie, I have an arbitrary number of plugins that can register to listen for a specific command and get a callback from bot.rb. (Eventually, I'd like to be able to reload these plugins without restarting the bot, too.)
I've looked at the ruby_events gem and I think this makes sense but I'm having a little trouble of figuring out the best way to architect things. My questions include...
I'm a little puzzled where to attach ruby_events listeners to - it just extends Object so it doesn't make it obvious how to implement it.
Bot is a module, so I can't just call Bot.send_data from one of the plugins to send data - how can I interact with the EM connection from one of the plugins?
I'm completely open to any architectural revisions or suggestions of other gems that make what I'm trying to do easier, too.
I'm not sure exactly what you're trying to do, but one common pattern of doing this in EM is to define the command handlers as callbacks. So then the command logic can be pushed up out of the Bot module itself, which just handles the basic socket communication and command parsing. Think of how a web server dispatches to an application - the web server doesn't do the work, it just dispatches.
For example something like this
EM::run do
bot = EM::connect $config_host, $config_port, Bot
bot.on_command_1 do |user, *args|
# handle command_1 in a block
end
# or if you want to modularize it, something like this
# where Command2Handler = lambda {|user, *args| #... }
bot.on_command_2(&Command2Handler)
end
So then you just need to implement #on_command_1, #on_command_2, etc. in your Bot, which is just a matter of storing the procs to instance vars; then calling them once you parse the passed commands out of your receive_data.
A good, very readable example of this in production is TwitterStream.
I've been trying to stub open, the open-uri version, and I'm not succeeding.
I've tried doing the following but the request keeps going through:
Kernel.should_receive(:open).and_return("Whatever for now")
I've also tried to do
OpenURI::OpenRead.should_receive(:open).and_return("Whatever for now")
Since I tracked down that was where HTTP requests were made in OpenURI.
Thanks in advance for any suggestions!
Here is what I do
class Gateway
def do_something
open('http://example.com').read
end
end
In my spec i do the following:
describe 'communication' do
it 'should receive valid response from example.com' do
gateway = Gateway.new
gateway.stub_chain(:open, :read).and_return('Remote server response')
gateway.do_something.should == "Remote server response"
end
end
I found a solution here on Stack Overflow after some more time on Google (I can't believe I didn't find this before).
Explanation taken from here and written by Tony Pitluga (not linkable).
If you are calling sleep within the context of an object, you should stub it on the object[...]
The key is, to stub sleep on whatever "self" is in the context where sleep is called.
So I did this and it all worked out:
let(:read) { mock('open') }
it "should return the new log-level when the log level was set successfully" do
read.stub(:read).and_return('log-level set to 1')
kannel.should_receive(:open).and_return(read)
kannel.set_log_level(1).should == 1
end
I'd recommend using something to stub the network instead. I believe the current favorite for doing so is FakeWeb [docs]. You may also be interested in fakeweb-matcher for rspec.
Alas, I think FakeWeb might not work with open(), actually, it stubs Net::HTTP, so I'm not sure if that will work. Any chance of not using open()? :)
I'm working on an application that reaches out to a web service. I'd like to develop a proxy class that returns a fake response from the service, so I don't have to constantly be hitting it with requests while I'm developing/testing other parts of the app.
My application is expecting a response generated via Net::HTTP.
response = Net::HTTP.get(URI.parse('http://foo.com'))
case response
when Net::HTTPOK
# do something fun
when Net::HTTPUnauthorized
# you get the idea
How can I manufacture a response object, give it all the right headers, return a body string, etc?
response = ProxyClass.response_object
case response
when Net::HTTPOk
# my app doesn't know it's being lied to
Thanks.
It's actually not that hard to roll your own fake responses directly with Net::HTTP. Here's a simple 200 OK with a cookie header:
def fake_response
net_http_resp = Net::HTTPResponse.new(1.0, 200, "OK")
net_http_resp.add_field 'Set-Cookie', 'Monster'
RestClient::Response.create("Body goes here", net_http_resp, nil)
end
Since few of us are using raw Net::HTTP anymore, the (optional) last line wraps it up as a RestClient::Response, which can then be stubbed into RestClient:
stub(RestClient).post(anything) { fake_response }
I would start with FakeWeb and see if that meets your needs. If it doesn't you can probably gut whatever you need out of the internals and create your own solution.
I know this post is old, but instead of FakeWeb which seems to be largely dead, try webmock. It seems to be more full-featured and very active.
I would look into a mocking library like mocha.
Then you should be able to setup a mock object to help test:
Then following example is from Tim Stephenson's RaddOnline blog, which also includes a more complete tutorial:
def setup
#http_mock = mock('Net::HTTPResponse')
#http_mock .stubs(:code => '200', :message => "OK", :content_type => > "text/html", :body => '<title>Test</title><body>Body of the page</body>')
end
For testing a web service client, we use Sinatra, a lovely little lightweight web framework that lets you get something up and running very quickly and easily. Check out the home page; it has an entire Hello World app in 5 lines of code, and two commands to install and run the whole thing.
I ended up using a Struct.
FakeHttpResponse = Struct.new(:status, :body)
http = FakeHttpResponse.new('success', 'body goes here')
http['status'] # = 'success'
http.body # = 'body goes here'
The drawback is that .status and ['body'] are also valid, but I don't think that matters much.
I would either use FakeWeb as mentioned above, or have my rake test task start a Webrick instance to a little sinatra app which mocks the various test responses you're hoping to see.
You could look into using Rack for this which should allow you to do everything you need.