Forum OpenACS Q&A: Response to brief acceptance test for 3.2.5
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!