I''m expecting my_test to raise one error or another, but since
I''m
pulling data from a db, I don''t know which error it will be. Is there
a
better way to write this?
expect { my_test }.to raise_error { |error|
error.should satisfy {|e|
e.instance_of?(OneError) || e.instance_of?(OtherError)
}
}
?
I''m not complaining, mind you -- I''m really impressed that
RSpec lets me
test for such specific pathology! I''m just wondering if
there''s another
matcher that won''t be quite so verbose.
- ff
--
Posted via http://www.ruby-forum.com/.
It depends on what you really mean: 1) If you care that it is either OneError or OtherError, then these are two separate scenarios and should be written as such. 2) If you don''t care which one it is, then you probably just be less specific. Is there a common message they respond to that you could check for? 3) If you care which error you are getting, but you don''t want to have to check for each one, then you might consider wrapping the error with something easier to inspect. There are probably a number of other good answers too, depending on which smell is bugging you the most. On Sat, Mar 9, 2013 at 3:20 PM, Fearless Fool <lists at ruby-forum.com> wrote:> I''m expecting my_test to raise one error or another, but since I''m > pulling data from a db, I don''t know which error it will be. Is there a > better way to write this? > > expect { my_test }.to raise_error { |error| > error.should satisfy {|e| > e.instance_of?(OneError) || e.instance_of?(OtherError) > } > } > > ? > > I''m not complaining, mind you -- I''m really impressed that RSpec lets me > test for such specific pathology! I''m just wondering if there''s another > matcher that won''t be quite so verbose. > > - ff > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20130309/b92517c4/attachment-0001.html>
On Sat, Mar 9, 2013 at 4:24 PM, Adam Sroka <adam.sroka at gmail.com> wrote:> It depends on what you really mean: > > 1) If you care that it is either OneError or OtherError, then these are > two separate scenarios and should be written as such. > > 2) If you don''t care which one it is, then you probably just be less > specific. Is there a common message they respond to that you could check > for? > > 3) If you care which error you are getting, but you don''t want to have to > check for each one, then you might consider wrapping the error with > something easier to inspect. > > There are probably a number of other good answers too, depending on which > smell is bugging you the most. >I don''t care which error I''m getting, so suggestion 2) works. The errors I expect are within a specific module (UpdateOrInsert::), so I could simply check for that. Not sure how do to that short of parsing the class name string (e.g. error_class.name.split("::")), but I''m not sure that is less smelly than the code I already have. I''ll contemplate 3), which could make life easer. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20130309/d96a072b/attachment.html>
It would be better to split that into two tests that test when each error is raised. On Mar 9, 2013, at 4:24 PM, Adam Sroka <adam.sroka at gmail.com> wrote:> It depends on what you really mean: > > 1) If you care that it is either OneError or OtherError, then these are two separate scenarios and should be written as such. > > 2) If you don''t care which one it is, then you probably just be less specific. Is there a common message they respond to that you could check for? > > 3) If you care which error you are getting, but you don''t want to have to check for each one, then you might consider wrapping the error with something easier to inspect. > > There are probably a number of other good answers too, depending on which smell is bugging you the most. > > > On Sat, Mar 9, 2013 at 3:20 PM, Fearless Fool <lists at ruby-forum.com> wrote: > I''m expecting my_test to raise one error or another, but since I''m > pulling data from a db, I don''t know which error it will be. Is there a > better way to write this? > > expect { my_test }.to raise_error { |error| > error.should satisfy {|e| > e.instance_of?(OneError) || e.instance_of?(OtherError) > } > } > > ? > > I''m not complaining, mind you -- I''m really impressed that RSpec lets me > test for such specific pathology! I''m just wondering if there''s another > matcher that won''t be quite so verbose. > > - ff > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20130309/63d417a7/attachment.html>
On Sat, Mar 9, 2013 at 6:08 PM, Samer Masry <samer.masry at gmail.com> wrote:> It would be better to split that into two tests that test when each error > is raised. >Except that the specific error that I receive depends on the ordering of the data in the database, which isn''t something I control. Hmm -- as I stare at that previous sentence, I detect a broader design smell rather than a specific code smell. I''ll go think about this... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20130309/68381095/attachment.html>
On 10 Mar 2013, at 02:04, Robert Poor <rdpoor at gmail.com> wrote:> On Sat, Mar 9, 2013 at 4:24 PM, Adam Sroka <adam.sroka at gmail.com> wrote: > It depends on what you really mean: > > 1) If you care that it is either OneError or OtherError, then these are two separate scenarios and should be written as such. > > 2) If you don''t care which one it is, then you probably just be less specific. Is there a common message they respond to that you could check for? > > 3) If you care which error you are getting, but you don''t want to have to check for each one, then you might consider wrapping the error with something easier to inspect. > > There are probably a number of other good answers too, depending on which smell is bugging you the most. > > I don''t care which error I''m getting, so suggestion 2) works. The errors I expect are within a specific module (UpdateOrInsert::), so I could simply check for that. Not sure how do to that short of parsing the class name string (e.g. error_class.name.split("::")), but I''m not sure that is less smelly than the code I already have. > > I''ll contemplate 3), which could make life easer. Thanks!Could you give both errors a common base class, then assert on that? cheers, Matt -- http://mattwynne.net || https://twitter.com/mattwynne || http://the-cucumber-book.com || http://bddkickstart.com || http://www.relishapp.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20130310/5fe8e727/attachment-0001.html>
On Sun, Mar 10, 2013 at 7:59 AM, Matt Wynne <matt at mattwynne.net> wrote:> Could you give both errors a common base class, then assert on that? >That''s the winning solution. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20130310/2827f5f5/attachment.html>