Rails - Mar 2006 - Unit test fails on different line the second time it''s run

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?

-- 
Posted via http://www.ruby-forum.com/.

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 3/25/06, Wiebe Cazemier <halfgaar@gmail.com>
wrote:
>
> 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?
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060325/c20c5601/attachment.html

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.




-- 
Posted via http://www.ruby-forum.com/.

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 3/25/06, Wiebe Cazemier <halfgaar@gmail.com>
wrote:
>
> 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.
>
>
>
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060325/666e0707/attachment.html

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

-- 
Posted via http://www.ruby-forum.com/.

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.


-- 
Posted via http://www.ruby-forum.com/.