Setting options in a custom `#as_json` method had side effects.
Modifications of the `options` hash leaked outside and influenced
the conversion of other objects contained in the hash.
This only works with mocha v0.13.0 or later.
Note that this also fixes a few subtle bugs present in the current
implementation :-
* Mocha was raising a `MiniTest::Assertion` instead of a
`Mocha::ExpectationError` as intended. The latter is not recognized by
MiniTest as an assertion failure and so it is recorded as a test
*error*, not a test *failure* as it ought to. This leads to
potentially confusing output in the test results.
* Mocha verification should happen as part of the test. The verification
of expectations is equivalent to a set of assertions. These assertions
should happen as *part of* the test so that they have a chance to
cause the test to fail, and not just as part of the teardown. Also if
an assertion fails during the test, then there is no need to verify
expectations, because only the first assertion failure is normally
reported and all subsequent bets are off.
* Expectation verification should be counted as an assertion. Mocha
cannot record each expectation verification as an assertion, because
we weren't passing in an assertion counter to `#mocha_verify`.
Two threads may be in method_missing at the same time. If so, they might
both try to define the same delegator method.
Such a situation probably wouldn't result in a particularly spectacular
bug as one method would probably just be overridden by an identical
method, but it could cause warnings to pop up. (It could be worse if
method definition is non-atomic in a particular implementation.)
(We will also need this mutex shortly anyway, see #8127.)
Most apps upgrading from 3.x will have options for mass assigment in
their application.rb and environments/*.rb config files. Rather than
just raising a NoMethodError when copying the config, this commit
adds a warning message until either the protected_attributes gem
is installed or the relevant config options are removed.
This allows us to avoid hacks like the "return 0 if owner.new_record?"
in #count (which this commit removes).
Also, the relevant foreign key may actually be present even on a new
owner record, in which case we *don't* want a null relation. This logic
is encapsulated in the #null_scope? method.
We also need to make sure that the CollectionProxy is not 'infected'
with the NullRelation module, or else the methods from there will
override the definitions in CollectionProxy, leading to incorrect
results. Hence the nullify: false option to CollectionAssociation#scope.
(This feels a bit nasty but I can't think of a better way.)
