When `ActiveRecord::Associations.eager_load!` is called, it eager loads
the `Preloader` but does not trigger a `eager_load!` on the `Preloader`
itself. A eager loaded component is responsible to forward the
`eager_load!` call to nested constants that make use of `eager_autoload`
as well.
This will also resolve the occasional `NameError` that we've observed in
production:
```
NameError: uninitialized constant ActiveRecord::Associations::Preloader::BelongsTo
```
This fixes an error where the test runner would try and run
XMLMiniEngineTest like a normal test class, except it's abstract. Now,
to circumvent this, we don't include any of the actual tests in
XMLMiniEngineTest; they are wrapped in a module that is included in
subclass when they inherit from XMLMiniEngineTest. Pretty neat, huh?
Created a new module (a la Action Cable subscription adapter's test
suite) to be included in all sub class test to ensure compatability and
reduce duplicated code.
When making the new command insfrastructure I had missed that
`bin/rails runner some_file.rb some args` would pass the extra
args onto the file in `ARGV`.
Now fixed by allowing the command to take extra args again, and
make sure to remove the file name from `ARGV`.
- Due to `assert_nothing_raised` this test was not really testing
anything.
- So updated it to assert that the query gives expected result.
- Also in general we can use `connection.unprepared_statement` for
testing queries w/o prepared statements but it can't be used in this
case. This test cases was added because when prepared_statements
config is set to false, then DetermineIfPreparableVisitor module
does not extended by Arel visitor resulting into an error. Ref: https://github.com/rails/rails/pull/22748.
- Because DetermineIfPreparableVisitor module does not get added to the
visitor chain only if prepared_statements is false while **setting up
connection**, not when `unprepared_statement` is used.
- I have also added an assertion for making sure that prepared_config
is set to false from the start, so that nobody accidentally removes
the connection setup using `arunit_without_prepared_statements` and
replaces it with stubs or unprepared_statement.
Now a few tests in ActiveModel rely on Ruby implementation and the fact
that in MRI `97.18` as a float is greater than `97.18` as a BigDecimal.
This is only relevant for MRI. On JRuby, comparing float to BigDecimal
would be conversion of them to the same type and they will be equal.
I'd like the ActiveModel test suite to be Ruby implementation-agnostic.
Here we test ActiveModel, not the Ruby internals.
This PR fixes a couple more JRuby tests.
- The query needs to be executed for hitting `select_all` so made sure
that query gets executed.
- Also instead of changing instance variable, just add new
configuration for prepared_statements: false and use it for this
test.
- This way we don't have to touch the internals of AR code and still
disable prepared statements config for this test.
Will help get rid of errors like the following:
```
1) Error:
JDOMEngineTest#test_order=:
ArgumentError: wrong number of arguments (0 for 1)
/Users/jon/code/rails/rails/activesupport/lib/active_support/core_ext/module/attribute_accessors.rb:106:in `test_order='
```
Rails routes (even rake routes in previous versions) output showed incorrect routes when an application use resource :controller, implying that edit_controller_path match with controller#show.
The order of the output has changed to correct this. View #26606 for more information.
Added a test case, change unit test in rake to expect the new output.
Since the output of resource :controller is changing, the string spected of the railties/test/application/rake_test.rb test_rails_routes_with_controller_environment had to be modified.
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 removes the following warnings.
```
/home/travis/build/rails/rails/activejob/lib/active_job/test_helper.rb:241: warning: shadowing outer local variable - job
/home/travis/build/rails/rails/activejob/lib/active_job/test_helper.rb:265: warning: shadowing outer local variable - job
```
- New apps generated on master and latest bundler give warning about
"github" source being insecure.
- Use the same solution used for Rails master in the generated app's
Gemfile to fix this issue.
The issue presented in #26246 showed a deeper underlying problem. When
we fell back to the exception handler for an exceptions cause, we were
calling that handler with the outer raised exception. This breaks the
calling code's expectations, especially if the exception has methods on
it behond those from `StandardError`.
