it was nice to meet the webware developers at ipc9. there are a lot of good
ideas in a webware and i think its got a bright future.
i worked up a regression testing proggie while at ipc9 for webware, its
attached, if this list denies attachments please just email me directly.
i really think regression testing is going to be key to showing off Webware's
growing maturity, not to mention shortening the number of silly bug fix
--usage aka how to make it work.
stick the attached file into webware's bin directory. it can be run either as
commandline executable or via
i've made every effort to make it os indepedent by using only os modules to
interact with the filesystem.
before it can be run, the Tests directory of every component needs to be
packagized by putting an __init__.py in the Tests directory.
-- how it works
basically it just does a path walk through the webware directory structure,
adding the base subdirectories to sys.path, looks for a directory named Test,
and files ending with Test.py which have a function makeTestSuite(), collects
the test suites and runs them with unittest's text test runner. it will try
to use the system's unittest but if thats not found it will use the one
included in Webware.
-- thoughts on current state of regression testing in Webware
i'm still using python 1.5.2 (cause of zope and a number of c extensions that
i use), so the regress test fail miserably for me since a growing portion of
webware is written in python 2.0 (this should be stated somewhere as a
requirement for webware).
the number of unittests seems to be to be dismally small, the lot of tests in
WebKit and MiddleKit are written without unittests, and need to be converted
over from the nonstandard variety they are currently.
-- some improvements that can be made to regress.py
don't add all the subdirectories to sys.path, either hard code acceptable
directories or look for __init__.py's in the subdirectory.
assign a priority to testing frameworks (easiest is probably via some sort of
intercomponent dependency list in Properties.py) so tests can be ordered in
some sort of heirarchy. granted this might be sugar, but as the number of
intercomponent dependencies or usage tests grows it might be useful.
who loves coding python and free choice more than being a zopitista.
At 03:36 AM 3/9/2001 -0800, ender wrote:
>assign a priority to testing frameworks (easiest is probably via some sort of
>intercomponent dependency list in Properties.py) so tests can be ordered in
>some sort of heirarchy. granted this might be sugar, but as the number of
>intercomponent dependencies or usage tests grows it might be useful.
In the future, components will advertise their dependencies, which
mitigates the need for this.
Thanks for the contribution. I'll take a closer look at it next week. (I'm
still in CA visiting with family.)