Where do I put this test?

Rails
1

I’m trying to use TDD on a Rails app. So far (6 hours into it) things
are going well.

My data model is starting to get a little more complex now. I now
have two related tables and I want to make sure my tests cover input
validation, record creation, and the proper creation of the foreign key.

Do I put this into a test unit for the parent table’s model?

Or do I test this via a controller method and put the test there?

I realize this is kind of like testing ActiveRecord and TDD advocates
against creating tests for 3rd party software, but I’m new to TDD and
am still trying to get the hang of it. Suggestions, pointers and
inspirational messages would all be appreciated.

Also, what’s the best practice for getting my _test database to track
my _development database? I’ve been using “rake
clone_structure_to_test” but I’m not sure that’s the best way to
accomplish this. I am using migrations for creating my data model…
can/should I rerun them against the _test db?

cr

2

On May 14, 2006, at 09:23 PM, [email protected] wrote:

I’m trying to use TDD on a Rails app. So far (6 hours into it)
things are going well.

Outstanding!

My data model is starting to get a little more complex now. I now
have two related tables and I want to make sure my tests cover
input validation, record creation, and the proper creation of the
foreign key.

Do I put this into a test unit for the parent table’s model?

You definitely put input validation into a Unit test for that model.

Or do I test this via a controller method and put the test there?

None of the three tests you’ve stated have anything to do with
templates, tags, params passing or sessions. So I would say that
rules out using a Rails functional test.

I realize this is kind of like testing ActiveRecord and TDD
advocates against creating tests for 3rd party software, but I’m
new to TDD and am still trying to get the hang of it. Suggestions,
pointers and inspirational messages would all be appreciated.

I would say this is correct, at least as it pertains to the second
and third tests that you mentioned. There is no business logic in
your models that specifically creates a database record (you create/
save AR objects), or assigns a foreign key to a database record (you
set AR associations). Thus you would not only be verifying things you
aren’t explicitly doing, but you are also writing tests for code that
someone else is responsible for testing.

That being said, if you do want to test for those things, both of
those test are Unit tests. The first should go into the unit test for
the model that you want to verify was created. The second I would
place in the model that is referred to by the foreign key, since an
instance of that model effectively “owns” an instance of the related
model, but you could go either way with it.

Also, what’s the best practice for getting my _test database to
track my _development database? I’ve been using “rake
clone_structure_to_test” but I’m not sure that’s the best way to
accomplish this. I am using migrations for creating my data
model… can/should I rerun them against the _test db?

I believe that all you need to do is turn on the Rails Environment
setting that always keeps a schema.rb file up to date with your
migrations. The _test database is built from the migration code in
that file. I’m not sure you need to use “rake
clone_structure_to_test” if you are correctly using migrations, but I
could be missing something…

-Brian

3

On May 14, 2006, at 8:23 PM, [email protected] wrote:

advocates against creating tests for 3rd party software, but I’m
new to TDD and am still trying to get the hang of it. Suggestions,
pointers and inspirational messages would all be appreciated.

I’ve been writing a couple test cases when I create new models. The
first, test_sanity, just goes through a CRUD cycle to make sure
everything works like I think it should. If I’ve got any sort of
associations going on, I write test_associations, again to test my
sanity and verify everything is as I think it should be.

Maybe I’ll stop writing these tests as AR becomes emblazened on my
brain. But, at the very least, they act as decent documentation for
someone to pick up my code and figure out what each unit should do.

~akk

4

I do the same thing. There’s nothing wrong with writing a sanity check,
just to make sure you’ve declared the association correctly.
ActiveRecord isn’t likely to be broken, but there’s always a good chance
of a typo somewhere in your own code. You’ll be surprised how many
typos you catch in sanity checks (I always am).

I wouldn’t worry too much about the “purity” of your tests. They’re
really there for you to build up a set of assertions to give you
confidence in your code. If it makes you feel good to write a simple
test so you know that the association is working correctly, then go for
it. You can always remove it later if it seems useless.

Ken