unit test question

Craig White wrote:

If there is a way to 'protect' me from deleting a CaseManager that has a Client within the model, I've not figured a way to do that...(Class CaseManager has_many :clients - Class Client belongs_to :case_manager)

Write a unit test which sets that scenario up, then calls...

   assert_raise_message RuntimeError, /has a Client/ do      manager.destroy    end

Then pass the test by any means necessary. Then write a functional test showing the Controller intercepts that error and displays an error message.

After you have the behavior pinned down, you are free to experiment with trapping that error at any level of the system - in your own Model code, in the ActiveRecord has_many declarations, or in Oracle.

This thread has gone on longer than I would have taken to put in the test and the questionable version of the code. I would only seek the elegant version after the feature itself was ready to deploy, so nobody needs to wait for it.

I have a bunch of data in my production db and my development db is my production db from January and migrated up to current. I am going backwards by trying to institute testing.

Move out this development db. Make enough test fixtures to test, and use rake db:fixtures:load to put them into your dev db. That's how we do it at work - sometimes we manually test with a grand-wazoo copy of the live database, and sometimes we manually test with the test fixtures.

The unit tests broke when I did things like 'rake test:functionals' or 'rake db:test:clone' etc. which give all appearance to drop the test db and recreate it from schema.rb (I'm surmising that this is what is occurring). With that, I lost the postgres 'CONSTRAINTS' which I was relying upon in some of my unit tests. If this is a bad concept to test for...then I will remove them.

Doesn't add_index create implicit constraints? We get that all the time in MySQL...

At the start of this thread I asked... and still haven't a clue why:

- testing like 'rake test:functionals' or 'rake test:units' acts as user postgres when I don't specify user postgres anywhere in database.yml at all. This completely defies explanation...I even went through my plugins and removed the postgres user from all plugin tests.

Ask again in a narrower thread with that in its title.

Also, I don't know either, except if that's just how Posgresql works!

- none of the commands like 'rake db:test:clone' or 'rake db:test:clone_structure' actually clone the development db including things like 'CONSTRAINTS' (and I presume TRIGGERS but I am not using them at the moment).

Maybe you could hotwire those to do what you want - call Posgresql commands to tell it to clone its db, without a round-trip thru Ruby. Write your own version of them in project.rake, and put p 'yo' inside, and see if you get a yo!

- using a postgres schema for testing seems pointless and counter productive. I've given that up completely. Someone suggested sqllite for test db which does make sense and I may end up going that route.

Me, but if you really want to go put biz logic inside Posgresql, it deserves tests. Erase your schema.rb, take out the environment line that creates it, add the line that creates development.sql, and try the cloners then.

Craig White wrote:

Maybe I'm just too dumb but it seems to me that the table constraints within postgres not only protect me from dumb actions in other software applications but also protected me from failing to catch bad 'destroy' actions that had related records in rails.

Craig - certainly valid points, the fact that you're thinking about it is the important part - do what feels right to you. You'll find that the argument about whether constraints should be db-enforced or code-enforced is a battle of religious "vi-vs-emacs" proportions. :slight_smile:

Cayce Balara wrote:

Craig White wrote:

Maybe I'm just too dumb but it seems to me that the table constraints within postgres not only protect me from dumb actions in other software applications but also protected me from failing to catch bad 'destroy' actions that had related records in rails.

Craig - certainly valid points, the fact that you're thinking about it is the important part - do what feels right to you. You'll find that the argument about whether constraints should be db-enforced or code-enforced is a battle of religious "vi-vs-emacs" proportions. :slight_smile:

Except when one tool doesn't work. Then you just switch to the other one and keep going.

(The real battle is titled DBAs who insist they "own" the database and nobody can change it, as a territory thing...)

> > - using a postgres schema for testing seems pointless and counter > productive. I've given that up completely. Someone suggested sqllite for > test db which does make sense and I may end up going that route. > Although there is an argument to say that your test environment should be close to the production environment. You don't want to find yourself writing code that works fine in sqlite, all tests pass etc.... but which doesn't in postgres. It's also a fact that rails validations etc... cannot guarantee integrity. Only the database can do that. And if your production environment enforces that but your tests don't then you could be building up to a problem: imagine that somewhere you accidentally leave a dangling reference. The test database has no constraints and doesn't care. The day you click that button in production postgres throws a wobbly because of a foreign key violation. I still don't get why it doesn't work though. You indicate that development_structure.sql (which is produced using pg_dump_ contains the constraints and all rake db:test:clone_structure does is pipe that file into psql so it's really odd that it's not working. If you know postgres well you could check the rake tasks to check they are invoking pg_dump and psql appropriately. With the :sql setting schema.rb should be touched at all and yet it is, which is just plain odd. Anyway, rake db:test:clone_structure should create development_structure.sql and load it into the test db, but if that's not working it's beyond me why,