Aggregating expects that require a block?

[DMA57361]

Have today noticed that RSpec 3.3 is out and that it includes a new aggregate_failures feature, which looks just like what I need to speed up a chronically slow test we have in one of our apps.

Unfortunately, on inspection, this test has plenty of the following within each of it's many many context's (the subject is a lambda that's running a processor of some kind):

it{ is_expected.not_to raise_error }
it{ is_expected.to change{ ReceivedMail.count }.by(+1) }
it{ is_expected.to change{ Ticket.count       }.by(+1) }
# and so on

I can't see a way that I can use these checks (presumably in the expect{ processor.run }.to ... form) in a manner that runs the block once and aggregates all the failures using the new feature, is this possible in some way?

---

Alternatively, I could manually store all the count values before, run the processor, then manually compare the results afterwards. This doesn't feel like a nice solution, but is probably what I'll be doing if the answer to the above it "no".

Also, I've also discovered I can do this:

is_expected
  .to  change{ ReceivedMail.count }.by(+1)
  .and change{ Ticket.count       }.by(+1)
  # and so on

which technically works, but produces failure messages that are a bit opaque:

     Failure/Error: .to  change{ ReceivedMail.count }.by(+1)
       expected result to have changed by 1, but was changed by 0 and expected result to have changed by 1, but was changed by 0 and expected result to have changed by 1, but was changed by 0

[myronmarston]

Doing compound expectations with and should give you better failure messages in the future when we implement #747. If you want to submit a PR for that that'd be great :).

Otherwise, another solution is to nest them:

expect {
  expect {
    do_it
  }.to change { ReceivedMail.count }.by(+1)
}.to change { Ticket.count }.by(+1)

I haven't tried that with the new aggregate_failures feature but I think that should work.

[myronmarston]

Closing as there's nothing directly actionable here. #859 is also improving the failure message for the compound case.