On Thu, Jan 29, 2009 at 3:50 PM, <r_j_h_box...@yahoo.com> wrote: > I'm starting to wonder if this is a good idea to begin with. I had started > to suggest nested it()s: > > it "..." do > it "something more" do > end > end > > ... but it's already handled by the existing nested describe(), before(), > it() system. > > I guess if we were shooting for flexibility, we might ask what the simplest > way is to the next level of flex? One route might be a detail level on > describe() blocks. So, suggestion #5: > > http://gist.github.com/54764 > > Then when generating spec docs, you could vary the detail level on what's > generated, to generate only up to level-2 documentation, or to generate > full-detail documentation if you prefer. > > Nested it()s could do the same thing, I suppose. Not sure what side effects > would come into play. Pretty clearly, a nested it() wouldn't have an > embedded transaction or respect the outer before() block, since the outer > if() would handle both those things.
For a number of technical reasons, the nested code example (it()) is a non-starter. The idea of having some means of flagging examples so they report differently is possible. Right now, example groups and examples each take a hash in their declarations: describe "an example group", :with => "some, :args => "like this" do it "an example", :with => "some", :other => "args" ... end end Those are accessible to the runner, and are used internally for assorted filtering. As of this moment, they don't make it past the reporters, because the object that goes to formatters is a wrapper w/ limited information instead of the real example. We could add the options to that wrapper though, and then you'd be able to write a custom formatter that would do anything you like based on the configuration of those options. WDYT about that? > > Randy > > > ________________________________ > From: aslak hellesoy <aslak.helle...@gmail.com> > To: rspec-users <rspec-users@rubyforge.org> > Sent: Thursday, January 29, 2009 1:27:02 PM > Subject: Re: [rspec-users] simple == with prettier error messages + good > documentation > > On Thu, Jan 29, 2009 at 10:14 PM, David Chelimsky <dchelim...@gmail.com> > wrote: >> On Thu, Jan 29, 2009 at 2:38 PM, Nick Hoffman <n...@deadorange.com> wrote: >>> On 29/01/2009, at 2:18 PM, David Chelimsky wrote: >>>> >>>> On Thu, Jan 29, 2009 at 1:02 PM, aslak hellesoy >>>> <aslak.helle...@gmail.com> >>>> wrote: >>>> On Thu, Jan 29, 2009 at 7:25 PM, David Chelimsky <dchelim...@gmail.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. >>>> >> >>>> >> 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 > >>> _______________________________________________ >>> 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 >> > > > > -- > Aslak (::) > _______________________________________________ > 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 > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
