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?
on 2006-03-25 14:11
on 2006-03-25 15:25
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
on 2006-03-25 15:45
Nick Stuart 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.
on 2006-03-25 16:07
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.
on 2006-03-25 16:24
Nick Stuart 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...
on 2006-03-25 16:33
Wiebe Cazemier 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.