Andrew: Thank you also for the reference. Important feature.
Peter: I have just started to look at the dotlrn installation scripts. I have an old copy so I'll update before I move too far forward. Thanks for pointing out the automation procs. I'll also start looking through the source tree for automated test definitions.
Here's a short blurb describing what I've determined since I began this thread last night.
The following utilities and features are
helpful when automating the tasks of installation, configuration,
development, and testing of an OACS system or package. These tasks are
repetitively performed hundreds of times while developing and testing
OACS packages and subsystems. While the tools described below may be
used for other purposes, their extreme value can be realized by
developers as they develop consistent, quality, error-free extensions
and modifications of an OACS system. Automating the error-prone, time
consuming, boring tasks of re-installation and initial configuration of
a system allows the developer to focus on the creative, non-repetitive
tasks required in the development process. This automation along with
the provision of an automated package TCL API tester *will* result in
higher quality and lower unit development cost. In addition, a
well-defined set of TCL API test instructions will result in lower
maintenance cost when unit modifications or extensions are necessary. Lastly (and most importantly), the existence of a package TCL API test suite will describe
the intended usage of a package's TCL API!
- The standalone tclwebtest tool is useful in manipulating the system at the HTML, or web UI, level. As such, it can be used both to test and configure the system. tclwebtest will retrieve pages, search for text in the response, fill-in and submit forms, and manipulate client cookies. Since this tool is written in TCL, the coder can utilize the power of this scripting language in his own test scripts.
- The acs-automated-testing package is useful in manipulating the system at the TCL API level. As such, it can be used in regression testing of packages and subsystems.
- The internal install.xml feature is useful when installing
a custom system. It defines application(s?) and describes settings and
actions associated with the application. This feature is an extension of
the OACS installation bootstrapping process. Its customization actions
are performed upon completion of OACS core installation, but prior to
the completion of the installation process.