When using RR in riot tests, most of the I find myself not caring about the return value of the last statement in the block, but rather whether RR's expectations were satisfied. As an example:
should "supply its command runner with the Worker's location" do
mock(topic.command_runner).run(topic.location, anything).times(2) {true}
topic.run
true
end
The true on the last time is ugly, but without it I get errors that riot got nil, and it expected non-false. While I realize that implicit failure inferred from the block's return value is a feature of riot, would you be open to reversing the default when Riot::RR support is enabled and a particular situation defines test doubles?
RR keeps track of the stubs/mocks in RR::Injections::DoubleInjection.instances, which would allow us to know whether to reverse the default (when its length > 0), or use riot's regular default (when it's empty).
When using RR in riot tests, most of the I find myself not caring about the return value of the last statement in the block, but rather whether RR's expectations were satisfied. As an example:
The true on the last time is ugly, but without it I get errors that riot got nil, and it expected non-false. While I realize that implicit failure inferred from the block's return value is a feature of riot, would you be open to reversing the default when Riot::RR support is enabled and a particular situation defines test doubles?
RR keeps track of the stubs/mocks in RR::Injections::DoubleInjection.instances, which would allow us to know whether to reverse the default (when its length > 0), or use riot's regular default (when it's empty).
Thoughts on supporting this?