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. -Ben _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users