# Where do I put this test? **URL:** \ **Category:** Rails\ **Created:** [May 15, 2006, 3:26am UTC](https://www.ruby-forum.com/t/where-do-i-put-this-test/94795 "2006-05-15T03:26:00Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [May 15, 2006, 3:26am UTC](https://www.ruby-forum.com/t/where-do-i-put-this-test/94795/1 "2006-05-15T03:26:00Z")
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 ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [May 15, 2006, 7:22am UTC](https://www.ruby-forum.com/t/where-do-i-put-this-test/94795/2 "2006-05-15T07:22:22Z")
On May 14, 2006, at 09:23 PM, removed\_email\_address@domain.invalid 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 ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [May 15, 2006, 5:54pm UTC](https://www.ruby-forum.com/t/where-do-i-put-this-test/94795/3 "2006-05-15T17:54:55Z")
On May 14, 2006, at 8:23 PM, removed\_email\_address@domain.invalid 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 > **[Adam Keys is typing](https://therealadam.com/)** > > Developer and engineering manager at large ---
**Author:** ![unknown](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/u/4bbf92/32.png) [@unknown](https://www.ruby-forum.com/u/unknown)\ **Post date:** [May 16, 2006, 5:26pm UTC](https://www.ruby-forum.com/t/where-do-i-put-this-test/94795/4 "2006-05-16T17:26:55Z")
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