Allow blocks on Faraday connections

[nhocki]

Hey Mark,

I'm adding the ability to use blocks when doing the requests. I have no idea on how to actually add a test for this, I've tried something like this but didn't work:

it 'passes a block' do
  block = Proc.new { |_, _| }
  klass.expects(verb).with(url, args, &block).returns(response)
  res = klass.send("#{verb}!", url, args, &block)
  res.body.must_equal body
end

It does however allow me to do something like this:

conn = Faraday.new(url: BASE_URL) do |builder|
  builder.request :url_encoded
  builder.adapter Faraday.default_adapter
end

conn.get! do |req|
  req.url url
  req.params = {foo: 'bar'}
  req.headers['Authorization'] = "Bearer #{access_token}"
  req.headers['Content-Type'] = 'application/json'
end

I'll gladly add tests if you can point me on how to do this.

Thanks!

[markbates]

Try this and see if it works:

it 'passes a block' do
  block = Proc.new { |_, _| }
  klass.expects(verb).with(url, args, block).returns(response)
  res = klass.send("#{verb}!", url, args, &block)
  res.body.must_equal body
end

[nhocki]

@markbates I also tried that and no luck, here's what I get:

 14) Failure:
Faraday::Bang::#post!::successful response#test_0002_passes a block [/Users/tarjan/code/faraday_bang/test/lib/faraday_bang/bang_test.rb:30]:
not all expectations were satisfied
unsatisfied expectations:
- expected exactly once, not yet invoked: Faraday.post('http://example.com', {:a => 'b'}, #<Proc:0x7f95b5182318>)
satisfied expectations:
- expected exactly once, invoked once: Faraday.post('http://example.com', {:a => 'b'})
- expected exactly once, invoked once: #<Mock:0x7f95b5183d08>.status(any_parameters)
- expected exactly once, invoked once: #<Mock:0x7f95b5183d08>.body(any_parameters)

[markbates]

http://stackoverflow.com/questions/3252046/mock-methods-that-receives-a-block-as-parameter

Why not change the test to assert something in the block happens when you call the bang method with a block?

That should prove that the block is getting passed through.

[nhocki]

@markbates I've updated this with two commits:

1. On 1980bd0 I fix a problem that was happening with the options method. It is not supported in Faraday (No method for OPTIONS HTTP verb lostisland/faraday#305) so I changed from send to run_request just for options.
2. On 0487f3f I added tests to method calls with blocks. The only thing I could think of that would be an actual test was to raise an exception inside the block, since assert false would be a failing test and assert true would not fail even if the blocks are not passed to the calls.

Please let me know how this looks and thanks a lot.

[markbates]

This can be more simply written as:

SUPPORTED_HTTP_METHODS = Faraday::Connection::METHODS - [ :options ]

[markbates]

@nhocki looks good. I added a few inline comments on a couple of things.

As soon as those are addressed I'll be happy to merge this in. Thanks.

[nhocki]

@markbates I added the tests for options but I didn't know how to add them with the same block... This happens because the tests expect for Faraday.<verb> to be called and now in options! we call run_request.

That's pretty much the only difference, so I'd love some help on removing the duplication there.

I also addressed your other comments.

Thanks,

[markbates]

At the end of the day it looks like everything calls run_request, could you change all the tests to assert that that is called with the correct options? That should clean everything up, I would think.

[nhocki]

@markbates the problem is that there is no "common" way of calling run_request.

For get, head, and delete it's called with a nil body (1), but for post, put, and patch it's called with a non-nil body (2).

[markbates]

In that case, screw it. I'm merging it. Thanks so much. Sorry that what should've been a simple PR turned into such a nightmare.

[nhocki]

Not a problem at all. Thanks for this gem!

Nicolás Hock Isaza

On Fri, Feb 6, 2015 at 4:21 PM, Mark Bates notifications@github.com
wrote:

Merged #1.

Reply to this email directly or view it on GitHub:
#1 (comment)