Coverage testing is a fundamental tenant of software engineering, whether or not one uses a current buzzword :)
Testing, automated and manual, is a sore point with the ACS in both Classic and OpenACS form. Ideally, aD - the company with dozens of software engineers who are actually PAID to work on the toolkit - would do adequate testing and also provide tools to help automate those bits of testing that can be automated (automated testing of web sites is far more difficult than for many classes of software, there are other threads on the issue here and at web/db). We could then depend on our ACS Classic base being solid and concentrate on ferreting out porting bugs. As it is, each of our release has included many bug fixes to the basic toolkit, which slows us down. The fact that we find and fix so many ACS Classic bugs while doing our ports is an indication to me that our core porting team believes that testing is important.
aD has made a lot of noise over their belated recognition that testing is important, and have made some steps to do more of it, but they still release broken software. Of course, all software's broken by definition, but ACS Classic is too frequently released with brokeness that even simple testing would uncover.
If you or someone else wants to step up to the plate and organize and improve testing of the OpenACS toolkit, above and beyond what the core porting team does while porting and users while using, you'd be deemed a hero. I'm serious - testing is far too often treated as a second-class activity, and testers as second-class contributors, but I don't think you'd find that attitude prevalent here.
Especially given the fact that we've all had lots of frustrating experience over the past year or so with untested, flakey software (the various ACS Classic releases).
