Sorry for late reply.
I'd say defer this to 3.4, or whatever will come after 3.3. For what
little
is left to do on 3.3 as it is, we are already bogging down.
Even just trying a quick run, came up with a few issues.
1. Can't decode Apache version string.
Traceback (most recent call last):
File "test.py", line 857, in ?
main()
File "test.py", line 812, in main
testsetup.apache_version = HttpdControl(options).version
File "test.py", line 357, in _get_version
self._version = [ int(p) for p in version_str.split('.',3) ]
ValueError: invalid literal for int(): 33 (Darwin)
This was when it picked up wrong httpd, ie., 1.33 standard on
Mac OS X.
Server version: Apache/1.3.33 (Darwin)
The format isn't what you were expecting. Ignoring that it was the
wrong version, might have to see if there is a more reliable way of
getting version in case vendors play with the string and how it is
formatted.
2. When told which Apache to use using --with-apxs, stopped
with:
Traceback (most recent call last):
File "test.py", line 857, in ?
main()
File "test.py", line 831, in main
list_tests(args, verbose=options.verbose)
File "test.py", line 84, in list_tests
msg = ' ' + ' (DISABLED)'.rjust(64 -len(name), '.')
TypeError: rjust() takes exactly 1 argument (2 given)
Don't know whether second argument to rjust is a Python 2.4 thing,
but not in Python 2.3.5.
Changed it to:
msg = ' ' + ' (DISABLED)'.rjust(64 -len(name)).replace(' ', '.')
although this is just cosmetic stuff anyway.
All but one test actually worked. The one that failed was because of
change I backed out related to:
http://issues.apache.org/jira/browse/MODPYTHON-171
For me this raises concerns as far as trying to include two separate
test frameworks in same package. Does this mean that test cases
have to be updated in two separate places during any transition
phase? Rather wait until we have a quiet patch when no serious
work being done or issues to address and then just concentrate purely
on this and cutover in one step so not duplicating stuff.
Graham
On 03/10/2006, at 7:01 AM, Jim Gallacher wrote:
When we started 3.3 development we discussed some of the
deficiencies of the current unit test framework, and the general
idea of a new design.
After a couple of ill-fated attempts at a rewrite I think I have
something that fits the bill. At this point it's actually usable,
and the code is not so horrible that I need to hang my head in
shame (I hope). It fact I feel that in it's current form it's
almost ready for inclusion in 3.3.0.
Grab it at:
http://people.apache.org/~jgallacher/mod_python/dist/
mod_python-3.3.0-test-ng.tgz
The test framework works as a standalone program. There is no ./
configure step. There is no need to compile mod_python to use it.
Untar it, take a look at the README, and then for a quick taste,
try some of the following examples:
$ python test.py -h
$ python test.py -l
$ python test.py -l core.session
$ python test.py core
$ python test.py --clean
$ python test.py core.publisher
$ python test.py --clean
$ python test.py -l core.request | grep -i sendfile > mytests
$ python test.py -i mytests
The last example creates new test class and handler templates for a
new test.
$ python test.py -a foo.bar.MyNewTest
Edit mptest/foo/bar.py and htdocs/foo/bar.py to perform whatever
test you had in mind and then run the test.
$ python test.py foo.bar.MyNewTest
The general idea is that the standard mod_python unittests go into
the "core" package. Non-standard tests (such as my leaktests) or
user defined application tests get separated into their own
packages, independent of the standard tests. The "foo" package is
one such example.
At this point the framework has only been tested in an environment
consisting of Ubuntu linux, apache 2.0.55, python 2.4.3 and
mod_python svn trunk, so it's entirely possible that it may blow up
with other platform configurations.
Grab a copy of it and let me know what you think. There are several
paths we can take with this new test framework.
1. Immediately replace the current test/ with test-ng/ for the 3.3
release.
2. Include both test/ and test-ng/ in the 3.3 release.
3. Defer it to 3.4.
4. Send it to /dev/null, never to be spoken of again.
Jim
