[rspec-users] Testing that named_scope is defined
helder at gmail.com
Wed May 14 14:32:37 EDT 2008
On Tue, May 13, 2008 at 11:50 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> Oi Helder,
Opa, beleza? :)
> On May 13, 2008, at 9:14 PM, Helder Ribeiro wrote:
>> On Tue, May 13, 2008 at 9:20 PM, Pat Maddox <pergesu at gmail.com> wrote:
>>> I wonder why OP doesn't create two records, call #most_recent, and
>>> verify that the record returned is the one with the larger timestamp.
>> I'm sorry about the confusion here. Your idea sounds indeed better
>> (I'll explain below).
>>> If the code is "not yours" (and I think you ought to clarify what you
>>> mean by that), then you should be testing it at a higher level instead
>>> of directly.
>> As I said, I'm not very familiar with specs and stuff, and I've read
>> repeatedly on this list and other places that one should only test
>> one's own code. That is, if you declare a has_many association, you
>> shouldn't test that the methods actually return the proper model
>> objects, etc., because that would be testing ActiveRecord. In that
>> same spirit, I thought I shouldn't test that a named_scope does what
>> it's supposed to, only that it is declared (because that one line is
>> all I wrote myself).
> You're thinking of this backwards. You are trying to test that you're using
> a specific method rather than expecting a behaviour. Specs are about
> behaviour. You're trying to backfill them against implementation.
> The behaviour you expect is to find the most recent posts, so that's what
> the example should expect. The fact that you're implementing that (which
> should happen after you write the example, not before) with named_scope
> instead of defining a method is an implementation detail. If you decide
> later that, for whatever reason, you want to change the implementation to a
> defined method, this example will still pass - or fail if you do the wrong
> thing. That's the whole point for executable examples. They encourage you to
> write the code you need and only the code you need, and then later they let
> you know whether changes you make to implementation preserve the behaviour
> that you are expecting.
> That all make sense?
Ok, that made a lot of sense, and for my particular case seems to be
the sensible approach. But where do you draw the line? Take the
ActiveRecord example. By the same logic you could argue that whatever
code you have that uses ActiveRecord should be spec'ed according to
its (your code's) expected behavior, regardless of it using
ActiveRecord or not under the hood. But then couldn't you end up
describing a lot of ActiveRecord's behavior along the way, which would
be kinda wasteful, since ActiveRecord is itself pretty well-tested
> ps - eu acho que você é brasileiro ou português por causa do seu nome - né?
>> But I guess I got a bit carried away, as in that declaration there is
>> stuff besides the declaration itself, namely, the bit specifying the
>> order. So it would be better to test for that, rather than just
>> testing if it was declared or not.
>> Thanks a lot for your help :)
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>> Helder Ribeiro
>> Embedded Systems
>> "If I have not seen as far as others, it is because giants were
>> standing on my shoulders" -- Jeff Goll
>> rspec-users mailing list
>> rspec-users at rubyforge.org
> rspec-users mailing list
> rspec-users at rubyforge.org
"If I have not seen as far as others, it is because giants were
standing on my shoulders" -- Jeff Goll
More information about the rspec-users