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) > _______________________________________________ > 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
