[Modeling-users] tests failing

[John Lenton]

I'm getting ready to create test cases for several of the patches that
are emerging from the work I've been doing in the last months; to
avoid regressions, I'm trying to make sure I have everything set up to
run the tests correctly, but several of the tests are failing, both in
0.9-pre-17.1 and current cvs, with the following message:

ValidationException: Validation for key books failed:
- Key is required but value is void
Validation for key OBJECT_WIDE_VALIDATION failed:
- Validation of object <test_EditingContext_Global.Writer_test07
object at 0x40ad3c6c> as a whole failed

the tests are from test_EditingContext_Global.py:
test_07_savechanges_01
test_09_savechanges_03
test_10_saveChanges_04
test_12_fetchingDoesNotUpdateSnapshot
test_17b_insertedObject_and_FK_as_classProperty
test_20_snapshot
test_22_cancel_delete

apart from these seven errors I get three failures, in

test_CooperatingObjectStoreNeededNotification.py:
test_01_initialState
test_EditingContext_Global.py:
test_00_insertObject_loads_databaseContexts
test_08_savechanges_02

and two extra failures in cvs head that seem to be harmless (different
ordering of attributes in a sql statement).

am I doing something wrong? I'm guessing the README is outdated,
because I tried that and it was even worse; I ran
'test_EditingContext_Global.py -r' and
'test_EditingContext_Global_Inheritance.py -r', and then 'run.py -g'.
These two give errors every time, complaining that

DROP INDEX WRITER_pkey
error: Couldn't evaluate expression DROP INDEX WRITER_pkey. Reason:
psycopg.ProgrammingError:ERROR: cannot drop index writer_pkey because
constraint writer_pkey on table writer requires it
HINT: You may drop constraint writer_pkey on table writer instead.

Also, one thing that isn't mentioned in the README is that the
database must be created with -E LATIN1, or it will produce an(other)
error.

[Sebastien Bigaret]

Hi John and all,

Post by John Lenton
I'm getting ready to create test cases for several of the patches that
are emerging from the work I've been doing in the last months; to
avoid regressions, I'm trying to make sure I have everything set up to
run the tests correctly, but several of the tests are failing, both in
- Key is required but value is void
- Validation of object <test_EditingContext_Global.Writer_test07
object at 0x40ad3c6c> as a whole failed
test_07_savechanges_01
test_09_savechanges_03
test_10_saveChanges_04
test_12_fetchingDoesNotUpdateSnapshot
test_17b_insertedObject_and_FK_as_classProperty
test_20_snapshot
test_22_cancel_delete
apart from these seven errors I get three failures, in
test_01_initialState
test_00_insertObject_loads_databaseContexts
test_08_savechanges_02
and two extra failures in cvs head that seem to be harmless (different
ordering of attributes in a sql statement).

I confirm your observations and the errors you see w/ the ./run.py -g
stuff also appear here. The fact is, I completely forgot about that
option, and I do not use it at all. Sorry about that.

Before this is fixed, you can have all the tests run w/ the procedure
described in the README: ./run.py (NO -g), plus the three
./test_EditingContext_XXX.py scripts.

--> The four test script should give zero error & zero warning w/
0.9pre17.1 (this is part of the procedure rnu before every release)

Post by John Lenton
am I doing something wrong? I'm guessing the README is outdated,
because I tried that and it was even worse; I ran
'test_EditingContext_Global.py -r' and
'test_EditingContext_Global_Inheritance.py -r', and then 'run.py -g'.
These two give errors every time, complaining that
DROP INDEX WRITER_pkey
psycopg.ProgrammingError:ERROR: cannot drop index writer_pkey because
constraint writer_pkey on table writer requires it
HINT: You may drop constraint writer_pkey on table writer instead.

Another bug here. Workaround: to regenerate the test databases, connect
to the admin. db template1, then

DROP DATABASE "AUTHOR_BOOKS";
CREATE DATABASE "AUTHOR_BOOKS";
DROP DATABASE "STORE_EMPLOYEES";
CREATE DATABASE "STORE_EMPLOYEES"

and finally run the scripts:
./test_EditingContext_Global.py -r
./test_EditingContext_Global_Inheritance.py -r

Your test-dbs should then be okay.

Post by John Lenton
Also, one thing that isn't mentioned in the README is that the
database must be created with -E LATIN1, or it will produce an(other)
error.

Third bug --could you be more explicit about the error? What is the
default encoding you use, and how can I reproduce it here (an other -E
option?) ?

If I may ask and I you have some time, could you submit bug reports
@sf.net please?

Anyway thanks a lot for the reports!

-- Sébastien.

[John Lenton]

On 06 Oct 2004 00:03:03 +0200, Sebastien Bigaret

Post by Sebastien Bigaret
Before this is fixed, you can have all the tests run w/ the procedure
described in the README: ./run.py (NO -g), plus the three
./test_EditingContext_XXX.py scripts.
--> The four test script should give zero error & zero warning w/
0.9pre17.1 (this is part of the procedure rnu before every release)

ok, except for the encoding errors, this is true here also.

Post by Sebastien Bigaret

Post by John Lenton
am I doing something wrong? I'm guessing the README is outdated,
because I tried that and it was even worse; I ran
'test_EditingContext_Global.py -r' and
'test_EditingContext_Global_Inheritance.py -r', and then 'run.py -g'.
These two give errors every time, complaining that
DROP INDEX WRITER_pkey
psycopg.ProgrammingError:ERROR: cannot drop index writer_pkey because
constraint writer_pkey on table writer requires it
HINT: You may drop constraint writer_pkey on table writer instead.

Another bug here. Workaround: to regenerate the test databases, connect
to the admin. db template1, then
DROP DATABASE "AUTHOR_BOOKS";
CREATE DATABASE "AUTHOR_BOOKS";
DROP DATABASE "STORE_EMPLOYEES";
CREATE DATABASE "STORE_EMPLOYEES"

createdb -E LATIN1 AUTHOR_BOOKS; createdb -E LATIN1 STORE_EMPLOYEES

works fine too (on debian, at least).

Post by Sebastien Bigaret
./test_EditingContext_Global.py -r
./test_EditingContext_Global_Inheritance.py -r
Your test-dbs should then be okay.

Post by John Lenton
Also, one thing that isn't mentioned in the README is that the
database must be created with -E LATIN1, or it will produce an(other)
error.

Third bug --could you be more explicit about the error? What is the
default encoding you use, and how can I reproduce it here (an other -E
option?) ?
If I may ask and I you have some time, could you submit bug reports
@sf.net please?

now I know which are bugs in Modeling and not bungles in my setup, I will.