Craig W. 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.
