[rspec-users] Specifying a Celluloid actor is still alive without a negative error expectation

Ash Moran ash.moran at patchspace.co.uk
Tue Aug 13 12:44:48 UTC 2013

On 13 Aug 2013, at 13:16, Andy Lindeman <andy at andylindeman.com> wrote:

> The problem with not_to raise_error is that it's a tad confusing. It
> could be interpreted either that you meant no error at all to be raised,
> or an error to be raised but not of the given type.

Hmmm, I always interpreted it as "I don't care what this block does, as long as it doesn't raise a FooError", which I suppose gives a third possible interpretation. I'd never considered the other interpretations, so I hadn't seen the potential for confusion myself until you pointed this out.

> I'd probably write it it as a positive:
>    expect { actor.method_that_raises_an_error }.to
>      raise_error(SpecificTypeOfErrorImExpecting)
> This will fail if the error ended up being a DeadActorError or if the
> method wasn't called but didn't raise an error.
> Does this help at all? I hope I understood you fully.

So this only solve a problem, but only one of them. The general pattern for this is that I need to specify two things in my code:

* A certain interesting piece of behaviour happens
* A certain type of error which a naive implementation would raise, isn't raised

In this case, the interesting behaviour is that an ArgumentError is raised, so I have this example (to save time replying, I'm no longer simplifying it, this is my actual example):

    it "is treated as the multiple arument case" do
      result.foo("one", "two", "three")
      expect { value }.to raise_error(ArgumentError, /3 for 1/)

Now I know that a naive implementation of the code behind `value` will crash the actor. So I need a separate example to check this is the case. But I don't want any knowledge of the behaviour of the method leaking into this example, so I'm currently resorting to this:

    it "doesn't crash the actor" do
      result.foo("one", "two", "three")

      expect {
        pass_handlers_to_result rescue nil
        rescue Exception => e
          raise if e.is_a?(Celluloid::DeadActorError)
      }.to_not raise_error

Which I'm sure you will agree, while arguably less ambiguous than `to_not raise_error(Celluloid::DeadActorError)`, lacks some of its terseness.

Hopefully this details the problem a bit more. Can you think of any improvements? I'm still at a loss unfortunately.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4837 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20130813/98357ca9/attachment-0001.bin>

More information about the rspec-users mailing list