On Thu, Jan 29, 2009 at 3:50 PM, <[email protected]> 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 <[email protected]> > To: rspec-users <[email protected]> > 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 <[email protected]> > wrote: >> On Thu, Jan 29, 2009 at 2:38 PM, Nick Hoffman <[email protected]> wrote: >>> On 29/01/2009, at 2:18 PM, David Chelimsky wrote: >>>> >>>> On Thu, Jan 29, 2009 at 1:02 PM, aslak hellesoy >>>> <[email protected]> >>>> wrote: >>>> On Thu, Jan 29, 2009 at 7:25 PM, David Chelimsky <[email protected]> >>>> wrote: >>>> > >>>> > >>>> > On Thu, Jan 29, 2009 at 12:00 PM, <[email protected]> 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 >>> [email protected] >>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >> _______________________________________________ >> rspec-users mailing list >> [email protected] >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > > > -- > Aslak (::) > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users > > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
