[rspec-users] spec'ing validates_uniqueness_of :whatever

Rick DeNatale rick.denatale at gmail.com
Fri Apr 4 07:31:51 EDT 2008

On Fri, Apr 4, 2008 at 2:12 AM, Steven Baker <steven at stevenrbaker.com> wrote:
> >> If you were to write an example that creates two models, and ensures
>  >> that the duplicate errored appropriately, my "rule" is violated.
>  >> Each
>  >> of your examples is then specifying the behaviour of the
>  >> validates_uniqueness_of method, which you didn't write.
>  >
>  > I don't really agree with this.  The desired behavior is to disallow
>  > two records with the same data.  v_u_o is simply a quick and easy
>  > means to that end.
>  Right.  As I said (or intended to) that particular example was so
>  simple that it was a grey area.  But it did cause me to think about
>  the problem, and I found it interesting.

While I certainly subscribe to the "don't test what you didn't write"
philosophy for the most part. I do think that there are gray areas.
Quoting Steven from a bit earlier in this thread:

> I don't exactly assume that the code I'm depending on is well tested,
> just that it's not my job to specify its behavior.

One of the gray areas is that despite all good intentions, sometimes
the specification of that behavior isn't entirely clear, even if that
specification is written down somewhere as specs, or traditional
documentation.  Problems can creep in when my understanding doesn't
exactly match the writer's intent.

In these cases, it seems to me that writing a spec which proves that
my interpretation of an interface by specifying the results rather
than just the presence of the call, just MIGHT be a reasonable thing
to do, and might protect against the possibility that the writer's
interpretation changes due either to evolution or a 'bug-fix.'

Rick DeNatale

My blog on Ruby

More information about the rspec-users mailing list