I have written up a set of scripts that can install a .LRN server from scratch non-interactively (without human interaction).

My vision for doing this was that we would have a canonical .LRN test server that gets recreated every morning with the latest source code and gets some standard setup with a few classes. If something breaks responsible people would be notified by email. This server would thus provide valuable regression tests and alert us early when things are broken. The server would also make it possible for developers to compare their own .LRN servers against the latest state of .LRN development. If you do download the TCLWebTest tool I recommend doing a cvs update -PAd since a lot seems to have been changed since the 0.1d version that is there.

My sincere gratitude and admiration goes out to Tilmann Singer for creating the excellent TCLWebTest tool. It's extremely easy to use, it's documented (not much software can claim that) and the code is well designed. I think the OpenACS community should decide on a testing framework and TCLWebTest is a strong candidate for being in such a framework. I encourage other people to try this tool and write some .LRN tests.

I will post here again once I have the test server up and I feel that I can publish my installation scripts.

I think it is needed and there are a lot of people that would test it.

I would like to see:

1. Two or three demo courses that show off the system (Sloan might have a course or two with content that someone would be willing to share with the world... we would also be willing to put some resources into a nice demo course)

2. Different test users (student, staff, professor, admin)

3. A big fat link to the bug tracker on the start page

carl: I would put the bug tracker link on _every_ page :) maybe in the footer

simon: what's "padi"?

Of course a lot of the base packages dotLRN is built on will be tested in the OpenACS sphere as part of our 4.6 release effort but the dotLRN package stuff itself needs to get tested by other means.  Fortunately Sloan's exercising the hell out of the Oracle version as you know.

Now ... that doesn't mean that OpenACS community members aren't going to offer to help test and fix the PG version (of course they will, we've seen a lot of this already).  It does mean that you're off the hook for organizing it and that it's not part of our OpenACS 4.6 release effort.

Apologies. I didn't mean to suggest that we didn't *want* to, or wouldn't *like* to test dotLRN, I was merely highlighting the fact that we simple don;t have the resources or volunteers required. I was also hihglighting the fact that dotLRN is far more specific as a platform, and therefore any test effort we do apply, will be more valuable if applied to the core.

As for organising I'd have no objection to including dotLRN in my remit, but..... how can I justify that when we as a community are not yet able to fully address our own core offering?


Now.... if I was overwhelemed with volunteers who would do testing (and do a fairly complete job ;), then this would not be the case.

Also, although I don't wish to give off the 'its their product' impression I do have to offer some gentle chastisment.


dotLRN is a proper, commercial and well backed effort with a paying customer. I don't think it is at all unreasonable to expect that OF, as the contracted firm, would perform and produce a reasonably comprehensive test plan/effort.

That is not to suggest that they are *obliged* to, but what concerns me is that they are going to be feeding a great deal of code into the OpenACS (hurray for that), but without any visible or transferable test effort. If this is the case then they are essentially increasing our QA burden....


If one was extremely synical one could argue that this is almost leaving the crappy jobs to the community! I don;t think thats what open source is about. Peer review provides many benefits, but it should not be substituted for a proper test effort.


Lets assume we were able able to perform a level of testing commensurate with the level of development... this would mean that the dotLRN stuff would add months and months of effort to a new release!


Basically the point is simple...


People are not taking testing a quality seriously enough!


Everyone vocalises its importance, but sadly there isn't the same actual test effort to back it up.

Lets get this sorted.... its good for everyone :)

set DIR "/tmp/"
cd $DIR

# Checkout a fresh copy from CVS. Note extra colon behind anonymous
# for empty password
exec cvs -d:pserver:anonymous:@cvs.tclwebtest.sourceforge.net:/cvsroot/tclwebtest checkout tclwebtest >> $DIR/tclwebtest.cvs.out 2>> $DIR/tclwebtest.cvs.err

# run selftests using the newly downloaded version
catch {
    exec sh $DIR/tclwebtest/tclwebtest $DIR/tclwebtest/selftest/ >> $DIR/tclwebtest.run.out 2>> $DIR/tclwebtest.run.err
}

puts "----- output of checked out version: -------"
set f [open $DIR/tclwebtest.run.out]
puts [read $f]
close $f
set f [open $DIR/tclwebtest.run.err]
puts [read $f]
close $f

Instead of the second exec call one could for example set it up to call recurse $DIR/modulename/tests/ to run the suite of tests that was included in the checkout.

File upload is important and it's on the TODO list, but I don't have time right now to add it (I will accept patches of course .

Regarding the select widgets - instead of doing a

field select $labeltext

you can directly set the value of a select field with

field fill $new_value

This will also accept values that are not in the option list.

Thanks for writing this script, Peter - mighty useful