| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Looking on code for this method it's clear that it's just returns `response.status` instead of full `response` object.
It's better to correct docs as probably lots of specs are relying on this behavior.
|
|
|
| |
Arcticle --> Article
|
|
|
|
|
|
| |
These files are not using `strip_heredoc`.
Closes #27976
|
|
|
|
| |
(I personally prefer writing one string in one line no matter how long it is, though)
|
| |
|
| |
|
|
|
|
|
| |
The rest of the helpers are better placed on Session -- and this is the
only one that cares which class it is defined on.
|
|
|
|
| |
Mention the Accept header and how that figures into the request format.
|
|
|
|
| |
Wrongly added when fixing the request path wrangling.
|
|
|
|
|
|
|
| |
Don't want to add defensive programming to this fairly
simple thing.
Fixes #27060.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of appending a format to the request, it's much better
to just pass a more appropriate accept header. Rails will figure
out the format from that instead.
This allows devs to use `:as` on routes that don't have a format.
Introduce an `IdentityEncoder` to avoid `if request_encoder`,
essentially a better version of the purpose of the `WWWFormEncoder`.
One that makes conceptual sense on GET requests too.
Fixes #27144.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reset a new session directly after its creation in
`ActionDispatch::IntegrationTest#open_session`. Reset the session to a clean
state before making it available to the client's test code.
Issue #22742 reports unexpected behavior of integration tests that run multiple
sessions. For example an `ActionDispatch::Flash` instance is shared across
multiple sessions, though a client code will rightfully assume that each new
session has its own flash hash.
The following test failed due to this behavior:
class Issue22742Test < ActionDispatch::IntegrationTest
test 'issue #22742' do
integration_session # initialize first session
a = open_session
b = open_session
refute_same(a.integration_session, b.integration_session)
end
end
Instead of creating a new `ActionDispatch::Integration::Session` instance,
the same instance is shared across all newly opened test sessions. This is
due to the way how new test sessions are created in
`ActionDispatch::IntegrationTest#open_session`. The already existing
`ActionDispatch::IntegrationTest` instance is duplicated with `Object#dup`,
This approach was introduced in commit 15c31c7639b. `Object#dup` copies the
instance variables, but not the objects they reference. Therefore this issue
only occurred when the current test instance had been tapped in such a way that
the instance variable `@integration_session` was initialized before creating the
new test session.
Close #22742
[Tawan Sierek + Sina Sadeghian]
|
| |
|
|
|
|
|
|
| |
This reverts commit 5dde413e1d14c42eb87071db20d075a7b962cb01.
Reason: The gem defines it so we don't need to remove
|
| |
|
|
|
|
| |
[ci skip]
|
| |
|
|
|
|
|
|
| |
`ActionDispatch::IntegrationTest`,
`#process`, `#get`, `#post`, `#patch`, `#put`, `#delete`, and `#head`.
|
| |
|
| |
|
|
|
|
|
| |
assigns assert the state of a controller instance what should not be
done in an integration test.
|
|
|
|
|
|
|
|
|
|
| |
When passed an already-valid file name, prepending the path is likely to
create problems.
This is particularly relevant for #26384, which adds fixture_path
handling to test classes that previously didn't have it: any existing
caller must have been manually locating the file, and we don't want to
break them.
|
|\
| |
| | |
Fix memoization bug on ActionDispatch::TestRequest#request_method=
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
TestRequest have been overrriding request_method setter since 2009,
but the actual implementation in Request (not TestRequest) has been
changed since that. Now it's also using @request_method instance
variable to keep the state.
The override in TestRequest have not been calling `super`, which caused
a bug that after accessing #requst_method the value was memoized and
then we've never been able to change it anymore:
```
req = ActionDispatch::TestRequest.create
puts "was: #{req.request_method}" # memoized here
req.request_method = "POST"
puts "became: #{req.request_method}"
```
output:
```
was: GET
became: GET
```
Since the whole purpose of overriding the setter in TestRequest is to
upcase it, I'm changing it to `super(method.to_s.upcase)`
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the check is failed, print the actual response body if it's not too large.
This could improve productivity when writing new tests.
Before:
```
ThemeEditorIntegrationTest#test_whatever
Expected response to be a <200: ok>, but was a <422: Unprocessable Entity>.
Expected: 200
Actual: 422
```
After:
```
ThemeEditorIntegrationTest#test_whatever
Expected response to be a <200: ok>, but was a <422: Unprocessable Entity>.
Expected: 200
Actual: 422
Response body: {"errors":["Invalid settings object for section '1'"]}
```
|
|
|
|
|
|
|
|
|
| |
Currently, `fixture_file_upload` does not work in integration test.
Because, `TestProcess` module has been include in `Session` class, but
`fixture_path` can not get from `Session` class.
Modify to include `TestProcess` in `IntegrationTest` class in order to get
correct value of `fixture_path`.
|
|
|
|
|
|
|
|
|
|
| |
This was almost every case where we are overriding `respond_to?` in a
way that mirrors a parallel implementation of `method_missing`. There is
one remaining case in Active Model that should probably do the same
thing, but had a sufficiently strange implementation that I want to
investigate it separately.
Fixes #26333.
|
|
|
|
| |
This allows us to not `||=` in `before_setup`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ActionDispatch::Integration::Runner.
In commit fa63448420d3385dbd043aca22dba973b45b8bb2, @tenderlove changed
the behaviour of the way `integration_session` is set up in this object.
It used to be the case that the first time it was accessed, it was
memoized with nil, however, this means that if it had already been set
it was not replaced. After that commit, it is now always set to `nil` in
the execution of `before_setup`.
In RSpec, users are able to invoke `host!` in `before(:all)` blocks,
which execute well before `before_setup` is ever invoked (which happens
in what is equivalent to a `before(:each)` block, for each test. `host!`
causes the integration session to be set up to correctly change the
host, but after fa63448420d3385dbd043aca22dba973b45b8bb2 the
`integration_session` gets overwritten, meaning that users lose their
`host!` configuration (see https://github.com/rspec/rspec-rails/issues/1662).
This commit changes the behaviour back to memoizing with `nil`, as
opposed to directly overwriting with `nil`. This causes the correct
behaviour to occur in RSpec, and unless I'm mistaken will also ensure
that users who want to modify their integration sessions early in rails
will also be able to do so.
|
|
|
|
|
|
|
|
| |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
|
|
|
|
|
| |
It's tough for people without the knowledge of where the `get` and
friends integration test helpers are defined to find documentation
for them. Add a link to the main integration test documentation.
|
|
|
|
|
|
|
| |
* Give the section a header to distinguish it from the general doc.
* Replace backticks with + signs to fit SDoc.
* Use double quoted strings.
* Clarify how `parsed_body` works — it doesn't depend on `as` anymore.
|
|
|
|
|
| |
At GitHub we need to handle parameter encodings that are not UTF-8. This
patch allows us to specify encodings per parameter per action.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In integration test when specify the "Accept" header with "xhr: true"
option, the Accept header is overridden with a default xhr Accept
header. The issue only affects HTTP header "Accept" but not CGI variable
"HTTP_ACCEPT".
For example:
get '/page', headers: { 'Accept' => 'application/json' }, xhr: true
# This is WRONG! And the response.content_type is also affected.
# It should be "application/json"
assert_equal "text/javascript, text/html, ...", request.accept
assert_equal 'text/html', response.content_type
The issue is in `ActionDispatch::Integration::RequestHelpers`. When
setting "xhr: true" the helper sets a default HTTP_ACCEPT if blank.
But the code doesn't consider supporting both HTTP header style and
CGI variable style.
For detail see this GitHub issue:
https://github.com/rails/rails/issues/25859
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a `GET` request is sent `as: :json` in an integration test the test
should use Rack's method override to change to a post request so the
paramters are included in the postdata. Otherwise it will not encode the
parameters correctly for the integration test.
Because integration test sets up it's own middleware,
`Rack::MethodOverride` needs to be included in the integration tests as
well.
`headers ||= {}` was moved so that headers are never nil. They should
default to a hash.
Fixes #26033
[Eileen M. Uchitelle & Aaron Patterson]
|
| |
|
|
|
|
| |
Fixes #25926
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we'd only assign a response parser when a request came through
Action Dispatch integration tests. This made calls to `parsed_body` when a TestResponse
was manually instantiated — though own doing or perhaps from a framework — unintentionally
blow up because no parser was set at that time.
The response can lookup a parser entirely through its own ivars. Extract request encoder to
its own file and assume that a viable content type is present at TestResponse instantiation.
Since the default response parser is a no-op, making `parsed_body` equal to `body`, no
exceptions will be thrown.
|
| |
|
|
|
|
|
|
| |
Felt that += overwriting the path variable was a little too hidden.
Make the outcomes easier to spot with an if-else branch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running tests with `--enable-frozen-string-literal` or
`# frozen_string_literal: true`, it's currently attempted to mutate the path
string in order to append the format, causing a `RuntimeError`.
```ruby
get '/posts', as: :json
```
```
RuntimeError:
can't modify frozen String
```
This commit fixes the problem by replacing the mutation with a concatenation,
returning a new string.
|
|
|
|
| |
Then just yield the location for the place where we need some extra processing.
|
|
|
|
| |
`if !var.nil?` is the same as just `if var`
|
|
|
|
|
|
|
|
| |
Currently, if path is a relative path, add format without the discrimination of the query.
Therefore, if there is a query, format at end of the query would been added,
format was not be specified correctly.
This fix add format to end of path rather than query.
|
|
|
|
| |
Follow up to #21671
|