> chained `change` matcher share the "actual" value or at least evaluate it
only once
If you expand the code
```
expect { action! }
.to change { A.count }
.and change { B.count }
```
it will be something like
```
prev_b = exp_block_b.call # last `change`
prev_a = exp_block_a.call # first `change`
action_block.call # and the return value is not passed around, but the
matcher has access to it
final_a = exp_block_a.call # first `change`
final_b = exp_block_b.call # last `change`
prev_a != final_a && prev_b != final_b
```
> Couldn't another 3rd-party matcher `pass` (or whatever) be part of that
chain?
Yes, but with the current implementation only if it's the first in the
chain. I.e. `expect { action! }.to pass.and change { A.count }` would work,
but `expect { action! }.to change { A.count }.and pass` won't.
> expect {
> expect(operation.call.success?).to eq true
> }.to change { A.count } .by(1)
That's the approach to use. However, I don't see an obvious way of making a
slick DSL out of it.
Let me check if it's possible to make Composable to pass not only the
"matches" flag, but also the return value of `action!` so that it's
automatically compatible with all block matchers.
- Phil
--
You received this message because you are subscribed to the Google Groups
"rspec" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/rspec/CAAk5Ok_Drekc-dFEeV21V6wDGruNRD7_FDekCq7xdcJ2Rbkkrw%40mail.gmail.com.
