Until 4.2.0, any test suite based on the `TestCase` classes provided by Rails would
always run into alphabetical, but now they run in random order. For now, we ensure
that our tests always run in alphabetical order.
Related commit on rails/rails
6ffb29d24e
This leaks into Devise mappings overriding the existing :admin one, so
depending on the test seed it fails like this:
$ TESTOPTS="--seed=9972" rake
==> Devise.orm = :active_record
Run options: --seed=9972
...
1) Failure:
MappingTest#test_allows_path_to_be_given [./test/mapping_test.rb:31]:
Expected: "admin_area"
Actual: "admin"
Using a different name should avoid any test randomization issues.
Previously the test was raising an ArgumentError by mistake:
ArgumentError: wrong number of arguments (0 for 1)
actionpack (4.1.4) lib/action_dispatch/routing/route_set.rb:328:in `eval_block'`
The #eval_block method expects a proc/lambda argument that can be
instance_exec'ed, not a real block. In the Rails implementation the block
is passed to #draw, which calls #eval_block internally passing the block
along, but as a Proc argument and not as a block.
Also the error we were raising from #devise_for was a RuntimeError,
changed to the expected ArgumentError. Adding an assertion on top of the
expected message should ensure we won't have this issue again.
This was introduced in 29da146c07, related
to #2802.
Also refactor tests to remove the custom failure app class only used
once in favor of an inline class for the specific test, makes it easier
to follow what's going on.
after_confirmation_path_for checks whether the user already signed in
by calling signed_in? after confirmation succeeded.
Since it was called without scope specification, the user treated as
signed in inappropriately when the user signed in as another resource
(such as 'admin').
Changes the behavior of `Devise.warden` such that calling it multiple
times with different blocks will result in a call to each block on
`Devise.configure_warden!` rather than "last block wins". This is
especially used for plugins that wish to extend warden functionality
without clobbering base app configuration or vice versa.
