I’ve got a very peculiar problem with unit tests. First, I clone my
development database with “rake clone_structure_to_test”, then I run my
test with “ruby investment_product_score_override_test.rb”. It fails on
line 68. Then, every test run after this, fails consistently on line 34.
How is this possible? I don’t use fixtures and I don’t use hardcoded
id’s or whatever. Unit tests are performed in a transaction, which is
rolled back when the test is done. So, how can the data of the first run
influence the second run? As far as I can see, the only thing that
changes, are the sequences, which shouldn’t be a problem, since I don’t
use hardcoded id’s.
Is there something else that lingers in the DB after a test is run?
Some actual code from the test would help here. In practice the test
runs
are completely separate from each other, because as you said, they are
running in transactions. Have you watched the test.log file to see whats
getting spit out while you run the test? It can be very informative.
-Nick
Nick S. wrote:
Some actual code from the test would help here. In practice the test
runs
are completely separate from each other, because as you said, they are
running in transactions. Have you watched the test.log file to see whats
getting spit out while you run the test? It can be very informative.
I deliberatly left out code, and tried to make a general description,
because I’m quite sure the code won’t help. There are extenstive
database triggers which modify the data, views to access tables, and the
code itself would require a lot of explanation. I was hoping someone
here had similair experiences, or would be able to give pointers where
to look.
I have diffed the test logs. They don’t show anything different, except
that the statements produced by the code in the teardown methods are
executed earlier, since the second run, the test fails earlier.
Well if there are triggers and such that will modify the data, then its
probably not rails fault at all, but something in the database thats
keeping
stuff around. As you said, the tests themselves run in transactions, but
I’m
not sure how executing triggers and such would behave in them.
Wiebe C. wrote:
I’ll check it again…
Okay, I think I should audition for the newest installment of “dumb and
dumber”. I used the primary id of a NEW record to pass to a function in
the trigger function, when I should have been using one of the foreign
keys… It works now.
Nick S. wrote:
Well if there are triggers and such that will modify the data, then its
probably not rails fault at all, but something in the database thats
keeping
stuff around. As you said, the tests themselves run in transactions, but
I’m
not sure how executing triggers and such would behave in them.
Anything that is done inside a transaction is aborted on rollback. This
includes anything done by triggers or rules. I’m quite sure of this, and
is confirmed by the fact that after a test, the test database is still
completely empty.
The assertion that fails in the second run, is a mutation which is done
by a trigger, which should not be executed at that point in the test.
The first it doesn’t, but the second run, the commands in the trigger do
get executed.
It would appear that the database(schema) is at fault, but I can’t seem
to find what it is. I’ve checked and double checked the
condition-function which is used by that trigger, but I can see nothing
wrong. I’ll check it again…