mocha developer - Sep 2006 - ActiveRecord Validations - validates_uniqueness_of

Hello,

I''m wanting to use Mocha and Stubba for my tests in place of the  
default Rails testing with fixtures.

I have the following class:

class Person < ActiveRecord::Base
   validates_uniqueness_of :email
end

and am wondering how I can test to ensure that the  
validates_uniqueness_of validation is running.

Any ideas?

-Jonathan

Good question actually.

The Person class methods will get executed during class read time
(i.e. when we first require Person).  Before double checking that, I
thought we might be able to do the following.

Person.expects(:validates_uniqueness_of).with(:email)

However, the first mention of Person parses the Person class, meaning
the expectation is not satisfied.  You can force it to re-read by
requiring relative to your test (i.e. add require
''../../app/models/person'' below the expectation).

I remember James working on something that deals with exactly this
situation but I can''t remember off hand what state it''s in -
James?

Chris

On 9/12/06, Jonathan Younger <daikini at gmail.com>
wrote:
> Hello,
>
> I''m wanting to use Mocha and Stubba for my tests in place of the
> default Rails testing with fixtures.
>
> I have the following class:
>
> class Person < ActiveRecord::Base
>    validates_uniqueness_of :email
> end
>
> and am wondering how I can test to ensure that the
> validates_uniqueness_of validation is running.
>
> Any ideas?
>
> -Jonathan
>
>
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

On 12/09/06, Chris Roos <chrisjroos at gmail.com>
wrote:
>
> I remember James working on something that deals with exactly this
> situation but I can''t remember off hand what state it''s
in - James?

Yes, this is part of what AutoMocha was trying to achieve, but it
hasn''t got
any further. As Chris explained, whatever you do, you need to set up
expectations before loading the class definition. One thing you may need to
ascertain is whether loading the class multiple times has any undesirable
consequences.
-- 
James.
http://blog.floehopper.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mocha-developer/attachments/20060913/a93fe651/attachment.html

On 9/12/06, Jonathan Younger <daikini at gmail.com>
wrote:
> Hello,
>
> I''m wanting to use Mocha and Stubba for my tests in place of the
> default Rails testing with fixtures.
>
> I have the following class:
>
> class Person < ActiveRecord::Base
>    validates_uniqueness_of :email
> end
>
> and am wondering how I can test to ensure that the
> validates_uniqueness_of validation is running.
I realize that this is a pretty old thread, but I was just catching up
and wanted to respond to this:

There is a saying in the TDD community that you should test YOUR code,
not other people''s code. There is also another viewpoint that you
should test behaviour, not implementation (BDD).

What I would really want to ensure here is that Person validates
uniqueness of email, not how it does it. What I would do is something
like:

def test_person_should_validate_uniqueness_of_email
  assert_true Person.new(:email => "a at b.com").save
  assert_false Person.new(:email => "a at b.com").save
end

The primary argument against this approach is that this test requires
real interaction w/ the database and unit tests aren''t supposed to
interact w/ the database. While I usually agree w/ that perspective, I
think that needs to be balanced against the fact that AR is very
closely tied to the database. So my approach tends towards testing the
behaviour (not the implementation) of model classes in the "unit
tests" allowing database interaction, but mocking/stubbing that
behaviour in "functional" and/or "integration" tests.

I''m curioius to hear other people''s perspective on this.

Thanks,
David

On 04/10/06, David Chelimsky <dchelimsky at gmail.com>
wrote:
>
> There is a saying in the TDD community that you should test YOUR code,
> not other people''s code. There is also another viewpoint that you
> should test behaviour, not implementation (BDD).

I''m sure both the ideas you mention above have been around for a long
time
and are not necessarily related to a particular community. To me, the idea
of "not testing other people''s code" mainly applies in the
context of unit
testing. I would still want to have higher-level tests that test the system
as a whole.

To me, the idea of "testing behaviour, not implementation" is the
difference
between black-box and white-box testing - not the difference between TDD and
BDD. I do not use a BDD framework, but my preference would always be to test
behaviour, because I think this leads to less brittle, more readable tests
where the intent is clear. However, I prefer to be pragmatic rather than
religious about avoiding testing the implementation.

What I would really want to ensure here is that Person
validates
> uniqueness of email, not how it does it. What I would do is something
> like:
>
> def test_person_should_validate_uniqueness_of_email
>   assert_true Person.new(:email => "a at b.com").save
>   assert_false Person.new(:email => "a at b.com").save
> end
>
> The primary argument against this approach is that this test requires
> real interaction w/ the database and unit tests aren''t supposed to
> interact w/ the database. While I usually agree w/ that perspective, I
> think that needs to be balanced against the fact that AR is very
> closely tied to the database. So my approach tends towards testing the
> behaviour (not the implementation) of model classes in the "unit
> tests" allowing database interaction, but mocking/stubbing that
> behaviour in "functional" and/or "integration" tests.
>
> I''m curioius to hear other people''s perspective on this.

I agree with your assessment that because AR is very closely tied to the
database, it''s sometimes hard to write tests that don''t access
the database.
However, your suggestion that unit tests should interact with the database,
but that functional or integration tests should not, seems very
back-to-front to me.

In a unit test context, I think it''s valid to argue that
validates_uniqueness_of is third party code and  does not need to be tested.
So conceptually I think think it would be useful to be able to test simply
that validates_uniqueness_of is called from the Person class definition with
the expected parameters. Of course this assumes that
validates_uniqueness_ofis tested thoroughly in AR tests (or at least
it''s being used by enough
people that we trust it to work!). If the uniqueness of a person''s
email
address is a critical business requirement of the system, I would expect a
high-level test to verify that requirement.
-- 
James.
http://blog.floehopper.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mocha-developer/attachments/20061006/a6e82b7a/attachment.html