Closed odlp closed 3 weeks ago
Rather than creating a new helper, I would rather the specs be setup with an around block that restores the original behaviour, and explicitly setting the values to
true
/false
in abefore
in thecontext
, I don't mind if you make a helper for the "restore" part (in an around hook) but I would strongly prefer it if the contexts set the correct values directly in a before.
👍 Updated to match the requested style
FWIW I find a block-based helper superior when temporarily mutating global state because that interface guarantees the state is reset (like Timecop safe mode for example).
I've worked in many codebases which mutate global state in before
hooks and don't have a corresponding after
or around
hook to reset said state, leading to order-dependent test failures. Appreciate this codebase is safeguarded with good code review with high standards... but to err is human and so on...
FWIW I find a block-based helper superior when temporarily mutating global state because that interface guarantees the state is reset (like Timecop safe mode for example).
I've worked in many codebases which mutate global state in before hooks and don't have a corresponding after or around hook to reset said state, leading to order-dependent test failures. Appreciate this codebase is safeguarded with good code review with high standards... but to err is human and so on...
An around hook is essentially a block based helper, the problem I had with it is the implementation obscured the actual config setting that was being set, as our specs act as part of our documentation its less obvious whats being tweaked, an alternative would be to use the without_partial_double_verification
block helper thats actually part of rspec-mocks
if you prefer.
@JonRowe
An around hook is essentially a block based helper
Very true.
an alternative would be to use the without_partial_double_verification block helper
I do use this in the other specs - but it sets a distinct flag Mocks.configuration.temporarily_suppress_partial_double_verification
rather than Mocks.configuration.verify_partial_doubles
. It's a pity in a way there are two flags at play here, but that's why we need to check both flags and test accordingly.
Overall I think the PR is fine now; I'm happy to adopt the house style and appreciate the trade-offs you mention between obscuring the config setting vs safety.
Thank you for this!
Released in 7.1.0
Following on from #2745, this PR skips the job/mailer verification that arguments match the signature when:
verify_partial_doubles
false#without_partial_double_verification
This direction was suggested by @JonRowe here:
Closes #2801.