Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: how about making verify_stubbed_calls verify the parameters of stubbed requests? #1291

Closed
yykamei opened this issue Jul 5, 2021 · 4 comments · Fixed by #1298

Comments

@yykamei
Copy link
Contributor

yykamei commented Jul 5, 2021

verify_stubbed_calls is a useful method to stub whether a request is exactly called within a production code.
However, I found out it does not verify the parameters of a request though it does for the request path.

For example, I'm expecting this test to fail because the new parameter foo is added to sushi, but the stubbed Faraday connection is expecting that the only abc exists in its params. However, the current implementation seems to pass the test.

class Client
  def initialize(conn)
    @conn = conn
  end

  def sushi(jname, **params)
    res = @conn.get("/#{jname}", **params)
    data = JSON.parse(res.body)
    data['name']
  end
end

RSpec.describe Client do
  let(:stubs)  { Faraday::Adapter::Test::Stubs.new }
  let(:conn)   { Faraday.new { |b| b.adapter(:test, stubs) } }
  let(:client) { Client.new(conn) }

  it 'verifies the all parameter values are identical' do
    stubs.get('/ebi?abc=123') do # <-- This expects only `abc` added, not including `foo`. Currently, this test unexpectedly succeeds!
      [
        200,
        { 'Content-Type': 'application/javascript' },
        '{"name": "shrimp"}'
      ]
    end

    expect(client.sushi('ebi', abc: 123, foo: 'Kappa')).to eq('shrimp')
    stubs.verify_stubbed_calls
  end
end

I succinctly came up with an idea to check all parameter keys are identical to the request parameters like this, but it would cause the existing tests to fail because of such a strict stubbing.

diff --git a/lib/faraday/adapter/test.rb b/lib/faraday/adapter/test.rb
index 0230b85..739b7ec 100644
--- a/lib/faraday/adapter/test.rb
+++ b/lib/faraday/adapter/test.rb
@@ -184,6 +184,8 @@ module Faraday
         end

         def params_match?(request_params)
+          return false unless Set.new(params.keys) == Set.new(request_params.keys)
+
           params.keys.all? do |key|
             request_params[key] == params[key]
           end

What do you think? This idea might bring breaking changes but would be useful when it comes to verifying the parameters.

@iMacTia
Copy link
Member

iMacTia commented Jul 5, 2021

Hi @yykamei and thanks for raising this issue!
I had a quick look at the test adapter and I believe we suffer from the same issue also on the headers side!
When we fix this issue for params, it would be great to do the same for headers as well.

That said, you also correctly pointed out my main concern:

This idea might bring breaking changes
I completely agree this would be useful, but the only requirement I'd have is that it would be opt-in.
In order to achieve that, we could introduce a strict_mode on the stubs object that can be arbitrarily enabled. When this is enabled, params and headers will be checked for an exact match.
By default, it will be disabled and behave like it does today.

How does that sounds? I'm open to other suggestions

@yykamei
Copy link
Contributor Author

yykamei commented Jul 5, 2021

Hi @iMacTia,

Thank you for your quick reply!
Yes, I think so. headers can be also checked more strictly as well.

strict_mode is fantastic! I couldn't conceive such an opt-in solution. This is great 👍

@yykamei
Copy link
Contributor Author

yykamei commented Aug 1, 2021

I opened a PR to address this issue on #1298. I hope this would be applicable to the current Faraday implementation.

@iMacTia
Copy link
Member

iMacTia commented Aug 1, 2021

Fantastic work @yykamei 👏
PR merged, closing this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants