On Thu, Jan 29, 2009 at 6:07 PM, Matt Wynne <m...@mattwynne.net> wrote: > > On 29 Jan 2009, at 22:20, David Chelimsky wrote: > >> On Thu, Jan 29, 2009 at 3:50 PM, <r_j_h_box...@yahoo.com> wrote: >>>>>>> >>>>>>> On Thu, Jan 29, 2009 at 12:00 PM, <r_j_h_box...@yahoo.com> wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I've found myself writing a thing I think is less than optimal, >>>>>>>> looking >>>>>>>> for suggestions. The context is, I'm testing a result, and as a >>>>>>>> part >>>>>>>> of >>>>>>>> that test, I might verify two or three things, which are >>>>>>>> individually >>>>>>>> relevant but not really discrete results (?). >>>>>>>> >>>>>>>> Here's my thinking process, using a toy example: >>>>>>>> >>>>>>>> foo.should == bar (or foo.should_not be_nil) >>>>>>>> >>>>>>>>> expected not to be nil, but was >>>>>>>> >>>>>>>> (hm, not very informative) >>>>>>>> >>>>>>>> if( foo == nil ) >>>>>>>> "failure to setup foo".should == "foo should be set to the thing >>>>>>>> that >>>>>>>> will be rendered" >>>>>>>> end >>>>>>>> >>>>>>>>> expected "foo should be set to the thing that will be rendered", >>>>>>>>> got "failure to setup foo" (using ==) >>>>>>>> >>>>>>>> I've used this, by example, for a test on a dependency >>>>>>>> (imagemagick), >>>>>>>> where if the dependency isn't found, I show a decent message with >>>>>>>> info >>>>>>>> the >>>>>>>> tester can use to resolve it. And, as I mentioned, I've used it for >>>>>>>> revealing more details in cases where the it "" + the generic error >>>>>>>> aren't >>>>>>>> informative. >>>>>>>> >>>>>>>> I'm satisfied using this method for things like detecting a failure >>>>>>>> to >>>>>>>> use >>>>>>>> a test-helper correctly - works fine, doesn't get in my way as part >>>>>>>> of >>>>>>>> the >>>>>>>> documentation. Which brings me to the problem I'm concerned about: >>>>>>>> >>>>>>>> With this method, nothing come out in the generated spec-docs to >>>>>>>> represent >>>>>>>> the thing I'm conditionally requiring. >>>>>>>> >>>>>>>> I guess I could get more fine-grained with my it()'s, but I've been >>>>>>>> preferring a more general statement for it(), that gives the sense >>>>>>>> without >>>>>>>> the detail. > > I really do suggest setting up the context in the before() block of a > describe (example group), then using each 'it' (example) to hold an > assertion. It's a tried and tested way of doing it for me, but it does take > some getting used to when you move over from xUnit style tests. > >>>>>>>> >>>>>>>> >>>>>>>> Any suggestions? >>>>>>> >>>>>>> I can't think of anything that wouldn't result in something that >>>>>>> requires >>>>>>> more writing as of now. Maybe we need a new construct like: >>>>>>> it "does something" do >>>>>>> with_message "this is a more specific message" do >>>>>>> foo.should == bar >>>>>>> end >>>>>>> end >>>>>>> WDYT? >>>>>>> >>>>>> >>>>>> I think that would be useful. Maybe make it more explicit that it's an >>>>>> error message: >>>>>> >>>>>> on_error "bla" do >>>>>> ... >>>>>> end >>>>>> >>>>>> on_failure "..." do ???? >>>>> >>>>> I like "on_failure", as it's consistent with RSpec's output. Eg: >>>>> 31 examples, 0 failures >>>>> >>>>> What could be done to make the construct more sentence-like? If used in >>>>> this >>>>> manner: >>>>> >>>>> it 'should do something' do >>>>> on_failure "@foo is nil" do >>>>> @foo.should_not be_nil >>>>> end >>>>> end >>>>> >>>>> It reads like this to me: >>>>> If "@foo is nil" fails, execute the block. >>>>> >>>>> These are a bit verbose, but what do you think these approaches?: >>>>> http://gist.github.com/54726 >>>> >>>> I'll take that gist and raise you one: >>>> >>>> http://gist.github.com/54750 (Suggestion #3) >>>> >>> >>> Upped: >>> >>> http://gist.github.com/54758 > > I do find myself hitting this sometimes, especially when I use rspec > assertions in Cucumber steps - I usually stick to one assertion per example > in RSpec so it isn't a problem when I'm writing unit tests. > > However we do have a couple of alternatives already, without extending RSpec > any more: > (1) just use traditional test/unit assertions instead (works OK in Cucumber > steps, though obviously they don't read quite so well) > (2) write a custom matcher > > We could also pretty easily extend the existing matchers, just taking a > failure message in the factory method, e.g: > > http://gist.github.com/54849 > > I agree this discussion should move to a ticket. But it seems I am to lazy > to do it myself ;)
http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/669 > > > Matt Wynne > http://blog.mattwynne.net > http://www.songkick.com > > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
