Forum: Ruby on Rails Unit test question!

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
DBC User (Guest)
on 2007-06-13 08:25
(Received via mailing list)
Hi,

I have a model and I am trying to do the testing. So my test code is
something like the following

def test_first
  assert_nil Person.find(1)
end

in this I am expecting the test to run against the development
database as only development database has the table. But when I ran,
it is failing because the test table is not found. Why is model
testing is pointing to test database anyway?

Thanks.
Pat M. (Guest)
on 2007-06-13 08:39
(Received via mailing list)
On 6/12/07, DBC User <removed_email_address@domain.invalid> wrote:
> in this I am expecting the test to run against the development
> database as only development database has the table. But when I ran,
> it is failing because the test table is not found. Why is model
> testing is pointing to test database anyway?
>
> Thanks.
>
>
> >
>

Why are you expecting it to run against the development database?  It
will run against whatever database is specified for the test
environment in database.yml.  Take a look at
http://glu.ttono.us/articles/2006/05/22/guide-envi...
to understand Rails environments.

Pat
Bob S. (Guest)
on 2007-06-13 19:01
(Received via mailing list)
On 6/13/07, DBC User <removed_email_address@domain.invalid> wrote:
>
> Hi,
>
> I have a model and I am trying to do the testing. So my test code is
> something like the following
>
> def test_first
>   assert_nil Person.find(1)
> end

This particular test isn't going to work. find(id) will raise an
exception if the row can't be found. If it can be found, it will
return the Person object. It will never return nil.

So you have a couple of options:

1. Use "assert_raise":

   assert_raise ActiveRecord::RecordNotFound do
      Person.find(1)
   end

2. Use find_by_id, which *will* return nil if the row isn't found:

   assert_nil Person.find_by_id(1)

>
> in this I am expecting the test to run against the development
> database as only development database has the table. But when I ran,
> it is failing because the test table is not found. Why is model
> testing is pointing to test database anyway?
>

It's because your test file includes "test_helper.rb" (as it should),
which sets the RAILS_ENV variable to "test".

You're fighting Rails here. If you create an empty test database and
then run "rake test", it will copy the development structure to the
test database and run the tests over there for you.

The reason for a separate test database is that you want a controlled
set of data to work with. The data in your development database is
constantly changing, so your test results wouldn't be stable.
Phlip (Guest)
on 2007-06-14 07:36
(Received via mailing list)
DBC User wrote:

> testing is pointing to test database anyway?
Because manual and automated tests should use different databases.

When you manually test, you need a generally sloppy set of records to
noodle
around with. Suppose you set up a given Person record, such as "Mr.
Frootloop". Each time you change the code and manually test, you want
the
same record to come back in the same state as you left it.

You should run your automated tests much more often than you manually
test.
Your automated should have an exact set of data fixtures, and you don't
need
the tests to die just because you manually changed a record. So you need
your tests to erase the entire database each time they run.

Put these rules together, and you need two databases. Your "manual test
fixture", Mr Frootloop, will not disappear just because you ran the
automated tests.

Tip: Configure the automated tests to run automatically, each time you
change the code. Then get in the habit of saving your files
deliberately,
and trying to predict the result of each test run. If you guess wrong,
you
can always Undo your last edit until the tests pass again. This is a lot
better than endlessly debugging!

--
  Phlip
  http://www.oreilly.com/catalog/9780596510657/
  "Test Driven Ajax (on Rails)"
  assert_xpath, assert_javascript, & assert_ajax
This topic is locked and can not be replied to.