Use kwargs in ActionController::TestCase and ActionDispatch::Integration HTTP methods #18323

Merged
merged 1 commit into from Jan 29, 2015

Conversation

Projects
None yet
@kirs
Member

kirs commented Jan 4, 2015

As @dhh suggested, controller HTTP methods are a prime candidate for kwargs.
post url, nil, nil, { a: 'b' } doesn't make sense.
More explicit way would be: post url, params: { y: x }, session: { a: 'b' }.

@rafaelfranca

View changes

actionpack/lib/action_controller/test_case.rb
+ session = args[0][:session]
+ flash = args[0][:flash]
+ else
+ parameters, session, flash = args

This comment has been minimized.

@rafaelfranca

rafaelfranca Jan 4, 2015

Member

We should deprecate this path or we will not be able to use kwargs for real here in the future.

@rafaelfranca

rafaelfranca Jan 4, 2015

Member

We should deprecate this path or we will not be able to use kwargs for real here in the future.

This comment has been minimized.

@rafaelfranca

rafaelfranca Jan 4, 2015

Member

Since we are deprecating all documentation and tests should use the kwarg implementation and we can remove the old implementation from the documentation keeping only a few tests to make sure it works and it is deprecated.

@rafaelfranca

rafaelfranca Jan 4, 2015

Member

Since we are deprecating all documentation and tests should use the kwarg implementation and we can remove the old implementation from the documentation keeping only a few tests to make sure it works and it is deprecated.

This comment has been minimized.

@kirs

kirs Jan 7, 2015

Member

Good point, thanks.

Here is rdoc syntax for usual arguments:

- +action+: The controller action to call.
- +http_method+: Request method used to send the http request. Possible values
  are +GET+, +POST+, +PATCH+, +PUT+, +DELETE+, +HEAD+. Defaults to +GET+.
- +parameters+: The HTTP parameters. This may be +nil+, a hash, or a
  string that is appropriately encoded (+application/x-www-form-urlencoded+
  or +multipart/form-data+).
- +session+: A hash of parameters to store in the session. This may be +nil+.
- +flash+: A hash of parameters to store in the flash. This may be +nil+.

Any suggestions how it will look like with kwargs? Couldn't find it in docs.

@kirs

kirs Jan 7, 2015

Member

Good point, thanks.

Here is rdoc syntax for usual arguments:

- +action+: The controller action to call.
- +http_method+: Request method used to send the http request. Possible values
  are +GET+, +POST+, +PATCH+, +PUT+, +DELETE+, +HEAD+. Defaults to +GET+.
- +parameters+: The HTTP parameters. This may be +nil+, a hash, or a
  string that is appropriately encoded (+application/x-www-form-urlencoded+
  or +multipart/form-data+).
- +session+: A hash of parameters to store in the session. This may be +nil+.
- +flash+: A hash of parameters to store in the flash. This may be +nil+.

Any suggestions how it will look like with kwargs? Couldn't find it in docs.

This comment has been minimized.

@dhh

dhh Jan 7, 2015

Member

New form should be:

process action, method: 'GET', params: {}, session: {}, flash: {}

And then we add on with:

post/get/put/patch/delete/head action, params: {}, session: {}, flash: {}

@dhh

dhh Jan 7, 2015

Member

New form should be:

process action, method: 'GET', params: {}, session: {}, flash: {}

And then we add on with:

post/get/put/patch/delete/head action, params: {}, session: {}, flash: {}

This comment has been minimized.

@kirs

kirs Jan 7, 2015

Member

Got it. I meant the rdoc syntax for describing kwargs

@kirs

kirs Jan 7, 2015

Member

Got it. I meant the rdoc syntax for describing kwargs

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 4, 2015

Member

We should do the same treatment to ActionDispatch::IntegrationTest.

Member

dhh commented Jan 4, 2015

We should do the same treatment to ActionDispatch::IntegrationTest.

@kirs

This comment has been minimized.

Show comment
Hide comment
@kirs

kirs Jan 4, 2015

Member

@dhh in the same PR or in the separate?

Member

kirs commented Jan 4, 2015

@dhh in the same PR or in the separate?

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Jan 4, 2015

Member

In the same

On Sun, Jan 4, 2015, 15:04 Kir Shatrov notifications@github.com wrote:

@dhh https://github.com/dhh in the same PR or in the separate?


Reply to this email directly or view it on GitHub
#18323 (comment).

Member

rafaelfranca commented Jan 4, 2015

In the same

On Sun, Jan 4, 2015, 15:04 Kir Shatrov notifications@github.com wrote:

@dhh https://github.com/dhh in the same PR or in the separate?


Reply to this email directly or view it on GitHub
#18323 (comment).

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 4, 2015

Member

We can do a separate PR for that. Just that we don’t want the two APIs to diverge in a release.

On Jan 4, 2015, at 9:04 AM, Kir Shatrov notifications@github.com wrote:

@dhh https://github.com/dhh in the same PR or in the separate?


Reply to this email directly or view it on GitHub #18323 (comment).

Member

dhh commented Jan 4, 2015

We can do a separate PR for that. Just that we don’t want the two APIs to diverge in a release.

On Jan 4, 2015, at 9:04 AM, Kir Shatrov notifications@github.com wrote:

@dhh https://github.com/dhh in the same PR or in the separate?


Reply to this email directly or view it on GitHub #18323 (comment).

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Jan 4, 2015

Member

Ha, I don't really care if it's the same or separate. But yeah, @rafaelfranca is probably right that we might as well treat it as one change. Since it's the same API. Although IntegrationTests also have env.

Member

dhh commented Jan 4, 2015

Ha, I don't really care if it's the same or separate. But yeah, @rafaelfranca is probably right that we might as well treat it as one change. Since it's the same API. Although IntegrationTests also have env.

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Jan 4, 2015

Member

Yeah, they can be different commits but I'd like to have the whole set of
changes grouped so we can link is release notes or even revert if needed.

On Sun, Jan 4, 2015, 15:08 David Heinemeier Hansson <
notifications@github.com> wrote:

Ha, I don't really care if it's the same or separate. But yeah,
@rafaelfranca https://github.com/rafaelfranca is probably right that we
might as well treat it as one change. Since it's the same API. Although
IntegrationTests also have env.


Reply to this email directly or view it on GitHub
#18323 (comment).

Member

rafaelfranca commented Jan 4, 2015

Yeah, they can be different commits but I'd like to have the whole set of
changes grouped so we can link is release notes or even revert if needed.

On Sun, Jan 4, 2015, 15:08 David Heinemeier Hansson <
notifications@github.com> wrote:

Ha, I don't really care if it's the same or separate. But yeah,
@rafaelfranca https://github.com/rafaelfranca is probably right that we
might as well treat it as one change. Since it's the same API. Although
IntegrationTests also have env.


Reply to this email directly or view it on GitHub
#18323 (comment).

@kirs

This comment has been minimized.

Show comment
Hide comment
Member

kirs commented Jan 19, 2015

@kirs kirs changed the title from Use kwargs in ActionController::TestCase HTTP methods to Use kwargs in ActionController::TestCase and ActionDispatch::Integration HTTP methods Jan 19, 2015

@dhh

View changes

actionpack/test/controller/integration_test.rb
- end
- end
-end
+# class MetalIntegrationTest < ActionDispatch::IntegrationTest

This comment has been minimized.

@dhh

dhh Jan 19, 2015

Member

Why is this test commented out?

@dhh

dhh Jan 19, 2015

Member

Why is this test commented out?

@dhh

View changes

actionpack/test/controller/live_stream_test.rb
end
capture_log_output do |output|
- get :exception_in_view_after_commit, format: :json

This comment has been minimized.

@dhh

dhh Jan 19, 2015

Member

format should be a stand-alone thing, but part of the params.

@dhh

dhh Jan 19, 2015

Member

format should be a stand-alone thing, but part of the params.

This comment has been minimized.

@kirs

kirs Jan 20, 2015

Member

Fixed.

@kirs

kirs Jan 20, 2015

Member

Fixed.

@dhh

View changes

actionpack/lib/action_dispatch/testing/integration.rb
# be +nil+,
# a Hash, or a String that is appropriately encoded
# (<tt>application/x-www-form-urlencoded</tt> or
# <tt>multipart/form-data</tt>).
- # - +headers_or_env+: Additional headers to pass, as a Hash. The headers will be
+ # - headers_or_env: Additional headers to pass, as a Hash. The headers will be

This comment has been minimized.

@dhh

dhh Jan 19, 2015

Member

Let's just call this headers. Hate that "or" setup. The headers get turned into env, that's fine. Don't need to spell that out further.

Actually, even better, let's do both, and just merge them together. Then it'll be even clearer in the code what the intent is.

@dhh

dhh Jan 19, 2015

Member

Let's just call this headers. Hate that "or" setup. The headers get turned into env, that's fine. Don't need to spell that out further.

Actually, even better, let's do both, and just merge them together. Then it'll be even clearer in the code what the intent is.

@rafaelfranca

View changes

actionpack/lib/action_dispatch/testing/integration.rb
+ # xhr :get, '/feed', params: { since: 201501011400 }
+ def xml_http_request(request_method, path, *args)
+ if kwarg_request?(*args)
+ # TODO slice

This comment has been minimized.

@rafaelfranca

rafaelfranca Jan 20, 2015

Member

This TODO need to be solved

@rafaelfranca

rafaelfranca Jan 20, 2015

Member

This TODO need to be solved

@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Jan 20, 2015

Member

Should we update the testing guide?

Member

rafaelfranca commented Jan 20, 2015

Should we update the testing guide?

@kirs

This comment has been minimized.

Show comment
Hide comment
@kirs

kirs Jan 20, 2015

Member

@rafaelfranca TODO is fixed, thanks! I will update the guide soon.

Member

kirs commented Jan 20, 2015

@rafaelfranca TODO is fixed, thanks! I will update the guide soon.

@kirs

This comment has been minimized.

Show comment
Hide comment
@kirs

kirs Jan 20, 2015

Member

@rafaelfranca guide updated.

Member

kirs commented Jan 20, 2015

@rafaelfranca guide updated.

@rafaelfranca

View changes

actionpack/lib/action_controller/test_case.rb
- # be +nil+, a hash, or a string that is appropriately encoded
+ # - action: The controller action to call.
+ # - params: The hash with HTTP parameters that you want to pass. This may be +nil+.
+ # - body: The request body with a string that is appropriately encoded
# (<tt>application/x-www-form-urlencoded</tt> or <tt>multipart/form-data</tt>).
# - +session+: A hash of parameters to store in the session. This may be +nil+.

This comment has been minimized.

@rafaelfranca

rafaelfranca Jan 20, 2015

Member

If we removed the fixed size of fonts of the other arguments we should do the same with session and flash.

@rafaelfranca

rafaelfranca Jan 20, 2015

Member

If we removed the fixed size of fonts of the other arguments we should do the same with session and flash.

This comment has been minimized.

@rafaelfranca

rafaelfranca Jan 20, 2015

Member

But I really not sure if we should remove it @fxn?

@rafaelfranca

rafaelfranca Jan 20, 2015

Member

But I really not sure if we should remove it @fxn?

This comment has been minimized.

@kirs

kirs Jan 21, 2015

Member

What do you mean under "fixed size of fonts"?

@kirs

kirs Jan 21, 2015

Member

What do you mean under "fixed size of fonts"?

This comment has been minimized.

@rafaelfranca

rafaelfranca Jan 21, 2015

Member

The +action+ over action.

@rafaelfranca

rafaelfranca Jan 21, 2015

Member

The +action+ over action.

This comment has been minimized.

@fxn

fxn Jan 21, 2015

Member

Yep, we should keep it.

@fxn

fxn Jan 21, 2015

Member

Yep, we should keep it.

This comment has been minimized.

@fxn

fxn Jan 21, 2015

Member

@kirs when you refer to variables, keyword arguments, etc. you use fixed-width font for them. That is assigns, rather than just assigns. Have a look at the API guidelines.

@fxn

fxn Jan 21, 2015

Member

@kirs when you refer to variables, keyword arguments, etc. you use fixed-width font for them. That is assigns, rather than just assigns. Have a look at the API guidelines.

This comment has been minimized.

@kirs

kirs Jan 21, 2015

Member

Thanks for review and explanation, I will fix it.

@kirs

kirs Jan 21, 2015

Member

Thanks for review and explanation, I will fix it.

@kirs

This comment has been minimized.

Show comment
Hide comment
@kirs

kirs Jan 24, 2015

Member

@rafaelfranca I added the CHANGELOG entry. Ready for merge?

Member

kirs commented Jan 24, 2015

@rafaelfranca I added the CHANGELOG entry. Ready for merge?

@robin850

View changes

actionpack/lib/action_controller/test_case.rb
@@ -491,58 +491,64 @@ def determine_default_controller_class(name)
end
end
- # Simulate a GET request with the given parameters.
+ # Simulate a GET request with the given keyword arguments.

This comment has been minimized.

@robin850

robin850 Jan 25, 2015

Member

"parameters" is maybe a better fit here ; "keyword arguments" is more an implementation detail and we are still passing the action as a normal parameter, not as a keyword argument. What do you think ?

@robin850

robin850 Jan 25, 2015

Member

"parameters" is maybe a better fit here ; "keyword arguments" is more an implementation detail and we are still passing the action as a normal parameter, not as a keyword argument. What do you think ?

@robin850

View changes

actionpack/lib/action_controller/test_case.rb
#
# You can also simulate POST, PATCH, PUT, DELETE, and HEAD requests with
# +post+, +patch+, +put+, +delete+, and +head+.
+ # Example sending parameters, session and setting a flash message:
+ #
+ # get :show

This comment has been minimized.

@robin850

robin850 Jan 25, 2015

Member

There's a missing comma here.

@robin850

robin850 Jan 25, 2015

Member

There's a missing comma here.

@robin850

View changes

actionpack/lib/action_controller/test_case.rb
@@ -567,40 +573,68 @@ def paramify_values(hash_or_array_or_value)
#
# - +action+: The controller action to call.
# - +http_method+: Request method used to send the http request. Possible values

This comment has been minimized.

@robin850

robin850 Jan 25, 2015

Member

It should be +method:+, no ? Also a nit-picky thing but maybe we can use "HTTP" instead of "http".

@robin850

robin850 Jan 25, 2015

Member

It should be +method:+, no ? Also a nit-picky thing but maybe we can use "HTTP" instead of "http".

@robin850

View changes

actionpack/lib/action_controller/test_case.rb
#
# To simulate +GET+, +POST+, +PATCH+, +PUT+, +DELETE+ and +HEAD+ requests
# prefer using #get, #post, #patch, #put, #delete and #head methods
# respectively which will make tests more expressive.
#
# Note that the request method is not verified.
- def process(action, http_method = 'GET', *args)
+

This comment has been minimized.

@robin850

robin850 Jan 25, 2015

Member

✂️

@robin850

robin850 Jan 25, 2015

Member

✂️

@robin850

View changes

actionpack/lib/action_dispatch/testing/integration.rb
@@ -12,12 +12,14 @@ module RequestHelpers
#
# - +path+: The URI (as a String) on which you want to perform a GET
# request.
- # - +parameters+: The HTTP parameters that you want to pass. This may
+ # - +parameters:+ The HTTP parameters that you want to pass. This may

This comment has been minimized.

@robin850

robin850 Jan 25, 2015

Member

It should be +params:+, no ?

@robin850

robin850 Jan 25, 2015

Member

It should be +params:+, no ?

@robin850

View changes

actionpack/lib/action_dispatch/testing/integration.rb
+ # params: { ref_id: 14 },
+ # headers: {"X-Test-Header" => "testvalue"}
+ def request_via_redirect(http_method, path, *args)
+ if kwarg_request?(*args)

This comment has been minimized.

@robin850

robin850 Jan 25, 2015

Member

It looks like you are duplicating some logic from process_with_kwargs, is it intended ? Otherwise, the method could look like:

def request_via_redirect
  process_with_kwargs(http_method, path, *args)

  follow_redirect! while redirect?
  status
end
@robin850

robin850 Jan 25, 2015

Member

It looks like you are duplicating some logic from process_with_kwargs, is it intended ? Otherwise, the method could look like:

def request_via_redirect
  process_with_kwargs(http_method, path, *args)

  follow_redirect! while redirect?
  status
end
@robin850

View changes

guides/source/testing.md
-* An optional hash of request parameters to pass into the action (eg. query string parameters or article variables).
-* An optional hash of session variables to pass along with the request.
-* An optional hash of flash values.
+* `params:` option with a hash of request parameters to pass into the action (eg. query string parameters or article variables).

This comment has been minimized.

@robin850

robin850 Jan 25, 2015

Member

Missing dot after the "e" of "e.g.". Also could you please wrap your lines around 80 chars editing the guides ? That would be awesome!

@robin850

robin850 Jan 25, 2015

Member

Missing dot after the "e" of "e.g.". Also could you please wrap your lines around 80 chars editing the guides ? That would be awesome!

@robin850

View changes

guides/source/testing.md
-* An optional hash of flash values.
+* `params:` option with a hash of request parameters to pass into the action (eg. query string parameters or article variables).
+* `session:` option with a hash of session variables to pass along with the request.
+* `flash` option with a hash of flash values.

This comment has been minimized.

@robin850

robin850 Jan 25, 2015

Member

Nit-picky missing colon. 😄

@robin850

robin850 Jan 25, 2015

Member

Nit-picky missing colon. 😄

@robin850

View changes

guides/source/testing.md
+* `session:` option with a hash of session variables to pass along with the request.
+* `flash` option with a hash of flash values.
+
+All the key arguments are optional.

This comment has been minimized.

@robin850

robin850 Jan 25, 2015

Member

s/key/keyword

@robin850

robin850 Jan 25, 2015

Member

s/key/keyword

@robin850

This comment has been minimized.

Show comment
Hide comment
@robin850

robin850 Jan 25, 2015

Member

Awesome work @kirs !

There's just a tiny missing change here to avoid displaying a deprecation warning running the test suite. Also, regarding deprecation warnings, you may want to use strip_heredoc instead of squish to keep the formatting. At the moment, it displays like this:

DEPRECATION WARNING: ActionDispatch::Integration::TestCase HTTP request methods will accept only keyword arguments in future Rails versions. Examples: get '/profile', params: { id: 1 }, headers: { 'X-Extra-Header' => '123' }, env: { 'action_dispatch.custom' => 'custom' } xhr :post, '/profile', params: { id: 1 }. (called from block (3 levels) in run at ...).

But well, that's just styling concerns, there's no big deal. Thank you !

Member

robin850 commented Jan 25, 2015

Awesome work @kirs !

There's just a tiny missing change here to avoid displaying a deprecation warning running the test suite. Also, regarding deprecation warnings, you may want to use strip_heredoc instead of squish to keep the formatting. At the moment, it displays like this:

DEPRECATION WARNING: ActionDispatch::Integration::TestCase HTTP request methods will accept only keyword arguments in future Rails versions. Examples: get '/profile', params: { id: 1 }, headers: { 'X-Extra-Header' => '123' }, env: { 'action_dispatch.custom' => 'custom' } xhr :post, '/profile', params: { id: 1 }. (called from block (3 levels) in run at ...).

But well, that's just styling concerns, there's no big deal. Thank you !

@robin850 robin850 added this to the 5.0.0 milestone Jan 25, 2015

@kirs

This comment has been minimized.

Show comment
Hide comment
@kirs

kirs Jan 25, 2015

Member

@robin850 thanks for review! You're also right about squish in deprecations. Will be fixed soon.

Member

kirs commented Jan 25, 2015

@robin850 thanks for review! You're also right about squish in deprecations. Will be fixed soon.

@kirs

This comment has been minimized.

Show comment
Hide comment
@kirs

kirs Jan 25, 2015

Member

@robin850 fixed 🚀

Member

kirs commented Jan 25, 2015

@robin850 fixed 🚀

Switch to kwargs in ActionController::TestCase and ActionDispatch::In…
…tegration

Non-kwargs requests are deprecated now.
Guides are updated as well.

`post url, nil, nil, { a: 'b' }` doesn't make sense.
`post url, params: { y: x }, session: { a: 'b' }` would be an explicit way to do the same
@kirs

This comment has been minimized.

Show comment
Hide comment
@kirs

kirs Jan 29, 2015

Member

Rebased one more time. ping @dhh @rafaelfranca @robin850

Member

kirs commented Jan 29, 2015

Rebased one more time. ping @dhh @rafaelfranca @robin850

@rafaelfranca rafaelfranca merged commit baf14ae into rails:master Jan 29, 2015

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

rafaelfranca added a commit that referenced this pull request Jan 29, 2015

Merge pull request #18323 from kirs/controller-test-kwargs
Use kwargs in ActionController::TestCase and ActionDispatch::Integration HTTP methods
@rafaelfranca

This comment has been minimized.

Show comment
Hide comment
@rafaelfranca

rafaelfranca Jan 29, 2015

Member

Awesome work @kirs

Member

rafaelfranca commented Jan 29, 2015

Awesome work @kirs

senny added a commit that referenced this pull request Jan 30, 2015

scaffold controller_test template should use kwargs. refs #18323.
This prevents a flood of warnings when generating a new scaffold.

maclover7 added a commit to maclover7/rails that referenced this pull request Apr 20, 2016

rafaelfranca added a commit that referenced this pull request Apr 21, 2016

@gkop

This comment has been minimized.

Show comment
Hide comment
@gkop

gkop May 7, 2016

Contributor

This is awesome work folks. I just wanted to point out to those struggling to make the new API work and get rid of the deprecation warnings (with ActionDispatch::IntegrationTest in my case) that you can pass a raw payload as a value to the :params named argument, it doesn't have to be a hash. Also there seems to be some logical branching going on whether or not you are using the old API or the new API. So don't expect eg. the :headers named argument (or, ahem, hash key ;) ) to be respected until you make the rest of your method call conform to the new API.

Contributor

gkop commented May 7, 2016

This is awesome work folks. I just wanted to point out to those struggling to make the new API work and get rid of the deprecation warnings (with ActionDispatch::IntegrationTest in my case) that you can pass a raw payload as a value to the :params named argument, it doesn't have to be a hash. Also there seems to be some logical branching going on whether or not you are using the old API or the new API. So don't expect eg. the :headers named argument (or, ahem, hash key ;) ) to be respected until you make the rest of your method call conform to the new API.

@kirs

This comment has been minimized.

Show comment
Hide comment
@kirs

kirs May 8, 2016

Member

@gkop thank you for suggestions! Do you mean that it would make sense to check if params and headers keys are hashes?

Member

kirs commented May 8, 2016

@gkop thank you for suggestions! Do you mean that it would make sense to check if params and headers keys are hashes?

@gkop

This comment has been minimized.

Show comment
Hide comment
@gkop

gkop May 8, 2016

Contributor

The most confusing thing about the new API is it wants you to pass eg. a POST request raw body as the value of the :params named argument; I would expect to pass the body as :body or, if the named argument accepts either a raw or structured body (like :params does currently), perhaps :payload.

The remaining confusion is only while supporting the old API and new API, you can't "mix and match", eg. send a raw string as the second argument and then a headers hash keyed on :headers in the options hash; that headers hash is then silently ignored. I'm not sure it's worth adding complexity to either respect the special values in the options hash or add a warning message if they're detected - I think good documentation of the new API (including covering how to send a raw POST body!) will mostly alleviate this confusion.

Contributor

gkop commented May 8, 2016

The most confusing thing about the new API is it wants you to pass eg. a POST request raw body as the value of the :params named argument; I would expect to pass the body as :body or, if the named argument accepts either a raw or structured body (like :params does currently), perhaps :payload.

The remaining confusion is only while supporting the old API and new API, you can't "mix and match", eg. send a raw string as the second argument and then a headers hash keyed on :headers in the options hash; that headers hash is then silently ignored. I'm not sure it's worth adding complexity to either respect the special values in the options hash or add a warning message if they're detected - I think good documentation of the new API (including covering how to send a raw POST body!) will mostly alleviate this confusion.

@dteoh

This comment has been minimized.

Show comment
Hide comment
@dteoh

dteoh Jul 7, 2016

Contributor

I don't suppose there is a way to preserve the types of objects when receiving a request?

In Rails 4.2:

put :update, obj: { attr_1: nil, attr_2: false }

the controller's params[:obj] will be as-is, i.e. { attr_1: nil, attr_2: false }.

After updating to Rails 5 and fixing deprecations:

put :update, params: { obj: { attr_1: nil, attr_2: false } }

the controller's params[:obj] will be { attr_1: "", attr_2: "false" }, i.e. every value is turned into a String.

Contributor

dteoh commented Jul 7, 2016

I don't suppose there is a way to preserve the types of objects when receiving a request?

In Rails 4.2:

put :update, obj: { attr_1: nil, attr_2: false }

the controller's params[:obj] will be as-is, i.e. { attr_1: nil, attr_2: false }.

After updating to Rails 5 and fixing deprecations:

put :update, params: { obj: { attr_1: nil, attr_2: false } }

the controller's params[:obj] will be { attr_1: "", attr_2: "false" }, i.e. every value is turned into a String.

@kirs

This comment has been minimized.

Show comment
Hide comment
@kirs

kirs Jul 7, 2016

Member

Douglas, AFAIK that's expected Rack behaviour because HTTP parameters are
always strings.

On Jul 7, 2016 03:23, "Douglas Teoh" notifications@github.com wrote:

I don't suppose there is a way to preserve the types of objects when
receiving a request?

In Rails 4.2:

put :update, obj: { attr_1: nil, attr_2: false }

the controller's params[:obj] will be as-is, i.e. { attr_1: nil, attr_2:
false }.

After updating to Rails 5 and fixing deprecations:

put :update, params: { obj: { attr_1: nil, attr_2: false } }

the controller's params[:obj] will be { attr_1: "", attr_2: "false" },
i.e. every value is turned into a String.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#18323 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAf3q-CTFDTzaZznCl7VHF659nWIyP-Cks5qTKl4gaJpZM4DOGBH
.

Member

kirs commented Jul 7, 2016

Douglas, AFAIK that's expected Rack behaviour because HTTP parameters are
always strings.

On Jul 7, 2016 03:23, "Douglas Teoh" notifications@github.com wrote:

I don't suppose there is a way to preserve the types of objects when
receiving a request?

In Rails 4.2:

put :update, obj: { attr_1: nil, attr_2: false }

the controller's params[:obj] will be as-is, i.e. { attr_1: nil, attr_2:
false }.

After updating to Rails 5 and fixing deprecations:

put :update, params: { obj: { attr_1: nil, attr_2: false } }

the controller's params[:obj] will be { attr_1: "", attr_2: "false" },
i.e. every value is turned into a String.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#18323 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAf3q-CTFDTzaZznCl7VHF659nWIyP-Cks5qTKl4gaJpZM4DOGBH
.

@dteoh

This comment has been minimized.

Show comment
Hide comment
@dteoh

dteoh Jul 8, 2016

Contributor

Fair enough. I expect that this change is going to break a lot of tests. I've got an API that deals with JSON request bodies. This new test class assumes only form encoded values and there is no public API to coerce the framework into interpreting String bodies as JSON. The :headers key as described in the docs currently do nothing.

I'm trying the following in a test, and looking at request.headers in the controller and see no evidence of the custom or overridden headers being passed along. Kinda confused about whether the tests are running through the full Rack + Rails stack or just some portions of it.

put :update, params: { obj: { attr_1: nil, attr_2: false } }, headers: { 'X_CUSTOM' => 'foobar', 'X-Custom' => 'something', 'CONTENT_TYPE' => 'application/json'  } 
Contributor

dteoh commented Jul 8, 2016

Fair enough. I expect that this change is going to break a lot of tests. I've got an API that deals with JSON request bodies. This new test class assumes only form encoded values and there is no public API to coerce the framework into interpreting String bodies as JSON. The :headers key as described in the docs currently do nothing.

I'm trying the following in a test, and looking at request.headers in the controller and see no evidence of the custom or overridden headers being passed along. Kinda confused about whether the tests are running through the full Rack + Rails stack or just some portions of it.

put :update, params: { obj: { attr_1: nil, attr_2: false } }, headers: { 'X_CUSTOM' => 'foobar', 'X-Custom' => 'something', 'CONTENT_TYPE' => 'application/json'  } 

@arthurkulchenko arthurkulchenko referenced this pull request in arthurkulchenko/qna_think Jul 13, 2016

Closed

Acceptance #3

@pawandubey

This comment has been minimized.

Show comment
Hide comment
@pawandubey

pawandubey Jul 19, 2016

Contributor

I have the same problem as @dteoh above. Even when specifying the format: :json the values in the params hash are converted to string. This has several hundreds of our specs failing right now.

Contributor

pawandubey commented Jul 19, 2016

I have the same problem as @dteoh above. Even when specifying the format: :json the values in the params hash are converted to string. This has several hundreds of our specs failing right now.

@dteoh

This comment has been minimized.

Show comment
Hide comment
@dteoh

dteoh Jul 19, 2016

Contributor

@pawandubey I just bit the bullet and switched over to ActionDispatch::IntegrationTest to make the tests work again. I added a few helper methods to the class to make the transition, and things work again.

Helper methods:

https://gist.github.com/dteoh/2d4c115446e2429824b6945c45c07f3b

Contributor

dteoh commented Jul 19, 2016

@pawandubey I just bit the bullet and switched over to ActionDispatch::IntegrationTest to make the tests work again. I added a few helper methods to the class to make the transition, and things work again.

Helper methods:

https://gist.github.com/dteoh/2d4c115446e2429824b6945c45c07f3b

@pawandubey

This comment has been minimized.

Show comment
Hide comment
@pawandubey

pawandubey Jul 20, 2016

Contributor

@dteoh Thanks, that was helpful, but I would like to keep using Rspec and achieve the same behavior(as it should be by default since rspec-rails is just a thin wrapper over the Rails helpers).

Contributor

pawandubey commented Jul 20, 2016

@dteoh Thanks, that was helpful, but I would like to keep using Rspec and achieve the same behavior(as it should be by default since rspec-rails is just a thin wrapper over the Rails helpers).

@connorshea

This comment has been minimized.

Show comment
Hide comment
@connorshea

connorshea Jul 20, 2016

Contributor

Anyone having trouble with this change specifically may want to take a look at the rails5-spec-converter gem

Contributor

connorshea commented Jul 20, 2016

Anyone having trouble with this change specifically may want to take a look at the rails5-spec-converter gem

@connorshea connorshea referenced this pull request in helpyio/helpy Jul 20, 2016

Open

Rails 5 #224

@trejkaz

This comment has been minimized.

Show comment
Hide comment
@trejkaz

trejkaz Aug 2, 2016

This warning was awfully hard to understand because by reading my code, it seemed like my params were already "keyword arguments". Now I understand that what it really means for all of my usages is that params can no longer be passed bare anymore.

trejkaz commented Aug 2, 2016

This warning was awfully hard to understand because by reading my code, it seemed like my params were already "keyword arguments". Now I understand that what it really means for all of my usages is that params can no longer be passed bare anymore.

@aaronrussell

This comment has been minimized.

Show comment
Hide comment
@aaronrussell

aaronrussell Aug 2, 2016

Is there a way of writing ActionController::TestCase tests that will pass in both Rails 5 and 4.2? (for rails engines that need to run in both)

Is there a way of writing ActionController::TestCase tests that will pass in both Rails 5 and 4.2? (for rails engines that need to run in both)

@connorshea

This comment has been minimized.

Show comment
Hide comment
@connorshea

connorshea Aug 2, 2016

Contributor

@aaronrussell they'll still pass in both, but will print deprecation warnings on 5.

Contributor

connorshea commented Aug 2, 2016

@aaronrussell they'll still pass in both, but will print deprecation warnings on 5.

kaspth added a commit that referenced this pull request Aug 13, 2016

Clarify xhr deprecation message. Don't support kwargs.
Prevent hitting integration tests users with two deprecation warnings by
clarifying how they should upgrade to the request helpers `get` and friends.

It's hard to imagine people having `xhr` calls that use keywords, why not
follow the xhr deprecation message? Why instead insert a middle layer of
migration?

They have to switch to something else anyway, so just show how that looks
and nudge them a bit more.

The code was originally added in #18323,
but then wasn't touched when deprecating xhr in
#18771.

edwardloveall added a commit to edwardloveall/pullfeed that referenced this pull request Nov 2, 2016

Add keyword arguments to integration/controller tests
rails/rails#18323/

Changes code like:

* get :show, params.merge(format: :atom)
* get(path, {}, headers)

to

* get :show, params: params.merge(format: :atom)
* get(path, params: {}, headers: headers)

Thanks to @rosmith76 and @asackofwheat

CGA1123 added a commit to CGA1123/F29SO that referenced this pull request Nov 28, 2016

Add basic edit/update functionality to `Profiles`
Adds both `html` and `js` responses allowing the editting/updating of
`first_name`, `last_name`, & `location` on a users profile.

Introduces the `profile.edit` & `profile.edit.others` permissions.

Removes the `Rail/HttpPositionalArguments` Cop from `rubocop`, this is
due to the fact that we're using `rails-4.2.7.1` and that cop is
intended to catch behaviour that was deprecated in this [PR](rails/rails#18323)
however that deprecation does not affect our current `rails` version.

@CGA1123 CGA1123 referenced this pull request in CGA1123/F29SO Nov 28, 2016

Merged

Add basic edit/update functionality to `Profiles` #43

jfragoulis pushed a commit to skroutz/cogy that referenced this pull request May 30, 2017

jfragoulis pushed a commit to skroutz/cogy that referenced this pull request May 30, 2017

jfragoulis pushed a commit to skroutz/cogy that referenced this pull request May 30, 2017

jfragoulis pushed a commit to skroutz/cogy that referenced this pull request May 30, 2017

jfragoulis pushed a commit to skroutz/cogy that referenced this pull request May 31, 2017

jfragoulis added a commit to skroutz/cogy that referenced this pull request May 31, 2017

jfragoulis added a commit to skroutz/cogy that referenced this pull request May 31, 2017

hanmd82 added a commit to hanmd82/contribulator that referenced this pull request Oct 16, 2017

Fix broken specs caused by migrating to Rails 5.1.x. Fixes #676
- update jsonapi initializer and corresponding JSON response keys
- add rails-controller-testing gem to support 'assert_template' and 'assigns'
  - see rspec/rspec-rails#1393
- update controller tests as Rails5 only accepts keyword arguments
  - see rails/rails#18323/

skalee added a commit to riboseinc/synced_resources that referenced this pull request Oct 19, 2017

Support new-fashioned kwargs-based request helpers
Rails 5 introduces a breaking change to request helpers synopsis.
Unfortunately, the modern way doesn't work in Rails 4, so we need to
choose between old and new helpers depending on Rails version.

See:
- rails/rails#18323/
- https://blog.bigbinary.com/2016/04/19/changes-to-test-controllers-in-rails-5.html

ronaldtse added a commit to riboseinc/synced_resources that referenced this pull request Oct 20, 2017

Support new-fashioned kwargs-based request helpers
Rails 5 introduces a breaking change to request helpers synopsis.
Unfortunately, the modern way doesn't work in Rails 4, so we need to
choose between old and new helpers depending on Rails version.

See:
- rails/rails#18323/
- https://blog.bigbinary.com/2016/04/19/changes-to-test-controllers-in-rails-5.html

@mklemme mklemme referenced this pull request in rspec/rspec-rails Jan 31, 2018

Open

Scaffold generator generates gets error on rails4. #1679

GabrielSandoval added a commit to GabrielSandoval/asyncapi-server that referenced this pull request Mar 13, 2018

Make gem Rails 5 compatible
- Use kwargs in HTTP request methods in rspec

See: rails/rails#18323/

GabrielSandoval added a commit to GabrielSandoval/asyncapi-server that referenced this pull request Mar 14, 2018

Make gem Rails 5 compatible
- Use kwargs in HTTP request methods in rspec
See: rails/rails#18323

@GabrielSandoval GabrielSandoval referenced this pull request in G5/asyncapi-server Mar 14, 2018

Open

Add Rails 5 compatible version #10

@waiting-for-dev waiting-for-dev referenced this pull request in waiting-for-dev/devise-jwt Mar 14, 2018

Closed

Adding additional test helpers to streamline testing flow #77

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