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