[rspec-users] simple == with prettier error messages + good documentation

r_j_h_box-sf at yahoo.com r_j_h_box-sf at yahoo.com
Thu Jan 29 16:50:12 EST 2009


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.

Randy




________________________________
From: aslak hellesoy <aslak.hellesoy at gmail.com>
To: rspec-users <rspec-users at 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 <dchelimsky at gmail.com> wrote:
> On Thu, Jan 29, 2009 at 2:38 PM, Nick Hoffman <nick at 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.hellesoy at gmail.com>
>>> wrote:
>>> On Thu, Jan 29, 2009 at 7:25 PM, David Chelimsky <dchelimsky at gmail.com>
>>> wrote:
>>> >
>>> >
>>> > On Thu, Jan 29, 2009 at 12:00 PM, <r_j_h_box-sf at 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 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
>



-- 
Aslak (::)
_______________________________________________
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/20090129/f93343af/attachment.html>


More information about the rspec-users mailing list