Forum OpenACS Development: Xowiki Regression Test

I tried running xowiki/admin/regression_test.tcl and got the following error

During this test:

Create and Render Index Page
OK: object name parsed - passed (0 ms)
OK: method passed from package initialize - passed (1 ms)
ERROR: index page resolved returned '0' ne '1'
ERROR: we have a page object returned '0' ne '1'

invalid command name "::"
while executing
"::$page_item_id item_id"
("uplevel" body line 1)
(procedure "?" line 1)
invoked from within
"? {expr {[::$page_item_id item_id]>0}} 1 "item_id given""
("uplevel" body line 126)
invoked from within
"uplevel {

If i run test.tcl I get this

Check Permissions based on default policy
OK: user_id is guest - passed (0 ms)
OK: the public cannot delete this page - passed (0 ms)
OK: the public cannot admin this package - passed (1 ms)
New Query: /XOWIKI-TEST/en/index

during '::xo::cc m view'
::xo::cc ::xotcl::Object->configure
::xo::ConnectionContext ::xotcl::Class->create
invoked from within
"my create ::xo::cc -package_id $package_id -parameter_declaration $parameter -user_id $user_id -actual_query $actual_query -url $url"
(procedure "require" line 16)
::xo::ConnectionContext->require
invoked from within
"ConnectionContext require -package_id $package_id -user_id $user_id -parameter $parameter -url $url -actual_query $actual_query"
(procedure "initialize" line 14)
::xowiki::Package ::xo::PackageMgr->initialize
invoked from within
"::xowiki::Package initialize -parameter $index_vuh_parms -package_id $info(package_id) -url /$instance_name/en/index -actual_query "" -user_id 0"
("uplevel" body line 152)
invoked from within
"uplevel {

Do we need both of those files? If one more up to date than the other?

I doubled checked and I have the most up to date test.tcl.

I restarted aolserver also and it did not help I still get this error:

"ConnectionContext require -package_id $package_id -user_id $user_id -paramete
r $parameter -url $url -actual_query $actual_query"
(procedure "initialize" line 14)
::xowiki::Package ::xo::PackageMgr->initialize
invoked from within
"::xowiki::Package initialize -parameter $index_vuh_parms -package_id $info(pac
kage_id) -url /$instance_name/en/index -actual_query "" -user_id 0"
("uplevel" body line 152)
invoked from within
"uplevel {
# regression test for xowiki

My previous install of xowiki seems to work OK, its just not passing the tests. I am not sure if this is a problem that will come up later so I would like to figure out what's causing the test to fail.

I did not have time yet to integrate my tests with automated testing. The "new framework" is not intended for the public, is about one page of code, and is much simpler than the automated testing notation. XOTcl (the language) uses the same "framework" since the beginning. It is simply the case that i am much faster developing tests this way. Nobody has to learn it, it is just for me. Read it this way: this file escaped from my environment, it is not documented, dave just saw it by observing the changelog of the cvs commits, he was curious, what it does and run it. Most probably, the test cases (containing the "framework") should be removed from cvs in order to avoid confusions.

Btw., these test cases of xowiki cannot be done via selenium. It seems that i have missed the consensus (most likely my fault), and i do not understand what "integrating" means (Selenium Core?, Selenium IDE?, Selenium RC?, all of these? with automated testing or just by-packing?). In my personal opinion, Selenium IDE is no big win over tclwebtest, since it can easily conflict with javascript based GUIs, ajax etc., which are becoming more important these days.

"integration" in this context mostly means providing a way to access selenium test from the automated test package, so those involved in evaluating code for release can go to one place to review test results. This will also be convenient when we (hopefully) resurrect the nightly build/test cycle we had implemented about three years ago.

Rolling your own is almost always going to be easier than doing things within the toolkit framework. Go for it. As long as you don't mind your code not being accepted into the toolkit as being part of a standard release of, oh, say, .LRN for instance.