On Thu, Mar 6, 2008 at 1:21 AM, Ben Mabey <[EMAIL PROTECTED]> wrote:
>
> Pat Maddox wrote:
>  > On Wed, Mar 5, 2008 at 4:22 PM, Rick DeNatale <[EMAIL PROTECTED]> wrote:
>  >
>  >> On 3/5/08, David Chelimsky <[EMAIL PROTECTED]> wrote:
>  >>  > On Mar 5, 2008, at 2:57 PM, "Rick DeNatale" <[EMAIL PROTECTED]>
>  >>  >
>  >>  > wrote:
>  >>  >
>  >>  >  > On Wed, Mar 5, 2008 at 1:31 PM, David Chelimsky
>  >>  >  > <[EMAIL PROTECTED]> wrote:
>  >>  >  >> On Mar 5, 2008, at 11:43 AM, "Rick DeNatale"
>  >>  >  >> <[EMAIL PROTECTED]>
>  >>  >  >>
>  >>  >  >> wrote:
>  >>  >  >>
>  >>  >  >>> On Wed, Mar 5, 2008 at 12:28 PM, Rick DeNatale <[EMAIL PROTECTED]
>  >>  >  >>>> wrote:
>  >>  >  >>>> I'm wanting to write a spec that a model is applying an :order
>  >>  >  >>>> option
>  >>  >  >>>> to a find call, but I don't want to completely specify all of the
>  >>  >  >>>> find
>  >>  >  >>>> parameters.
>  >>  >  >>>>
>  >>  >  >>>> So I want to write something like this, say in a controller spec
>  >>  >  >>>>
>  >>  >  >>>>  User.should_receive(:find).with(:all, hash_with_at_least(:order 
> =>
>  >>  >  >>>> 'user.name ASC'))
>  >>  >  >>>>  get 'index', :sort => 'up'
>  >>  >  >>
>  >>  >  >> I really like this idea. What about something more general that can
>  >>  >  >> handle the first n args too?
>  >>  >  >
>  >>  >  > That's a horse of a different color I think.  It would need to dig
>  >>  >  > into MessageExpectation#with and/or the way ArgumentExpectations are
>  >>  >  > built.
>  >>  >  >
>  >>  >  > Dealing with it an argument at a time is easy since it just needs ==
>  >>  >  > to 'do the right thing' on an argument 'proxy'.
>  >>  >
>  >>  >
>  >>  > Agreed.
>  >>  >
>  >>  >  I think hash_with would be clear enough and a bit more terse. Agree?
>  >>
>  >>  Well that name has been bandied about for other purposes
>  >>  http://www.google.com/search?q=hash_with
>  >>
>  >>  Maybe  options_with since I think Rails tends to call a trailing hash
>  >>  argument options, or looking ahead to ruby 1.9, keywords_with
>  >>
>  >>  These still don't really feel exactly right to me though since they
>  >>  don't carry the connotation that other key/values are acceptable.
>  >>
>  >>  Another alternatives, which trade off slightly less brevity for a bit
>  >>  more clarity, might be hash_including
>  >>
>  >>  Personally, since most folks use capable editors, I'm less concerned
>  >>  with minimizing keystrokes, for example in textmate, a longer and
>  >>  clearer version can be had for the cost of an esc key or a snippet.
>  >>  <G>
>  >>
>  >
>  > Am I the only one that hates this whole thing and thinks it ought to be
>  > User.should_receive(:all_sorted_by_name)
>  >
>  > ?
>  >
>  > Pat
>  > _______________________________________________
>  > rspec-users mailing list
>  > rspec-users@rubyforge.org
>  > http://rubyforge.org/mailman/listinfo/rspec-users
>  >
>
>  I thought the same thing, but I have also wanted to only check certain
>  keys in a hash before so I think that is really what this discussion is
>  about.  Whether or not that logic should be in the model is somewhat
>  inconsequential because the functionality that is being proposed could
>  be used elsewhere.  I think having this would allow specs to be more
>  flexible and not tie them to the implementation as much in some cases.

+1

David


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

Reply via email to