An Acceptance Test for OpenACS is definitely a Good Thing (TM)!
Thanks for taking this on, I hope you'll be able to really develop
a good set of acceptance tests for OpenACS. Automating them as much
as possible would also be very helpful. As a general principle, I
would suggest trying to find alternate tests for each test that seems
to fail, rather than just saying "it is OK for test X to fail". Ideas
follow:
to_date() returns '0002-12-29 BC': I think this is an artifact
of the
supplied date '1-1-2000' NOT being in the format of DD-MM-YYYY but having
single digit D and M fields. The query
select to_date('01-01-2000', 'MM-DD-YYYY') as y2k from dual ;
yields the expected answer (under PG 7.1 at least). So this may
actually be the aD acceptance test testing something slightly
different from what will actually be needed within the system. The
OpenACS to_date() could probably be fixed to handle this
case, but someone with more knowledge of the guts of OpenACS than me
will need to decide whether it would actually help anything other
than just this one (artificial) test or not.
user_tables missing: The equivalent (near as I can tell) in
OpenACS would be
select distinct table_name from user_tab_columns where
lower(table_name) in ('country_codes', 'states', 'counties') ;
Registration and User Administration:
I think much of what you are saying needs testing here is effectively
tested if you follow the instructions in the OpenACS Installation
Guide about creating a user for yourself and making that user an
admin, and changing the system user password. This is in Section 6.4,
and running the acceptance tests is in 6.7.
This is not necesrily a bad thing. However, it also means that by
the time you run the Acceptance Tests, the
password of the 'system' user should not be 'changeme', because
you would have changed it back in Section 6.4.
I hope these ideas help you improve your document further!
