quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <grah...@dscpl.com.au>
Subject Re: New mod_python unittest framework
Date Sun, 08 Oct 2006 04:24:31 GMT
Sorry for late reply.

I'd say defer this to 3.4, or whatever will come after 3.3. For what  
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 ?
   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

2. When told which Apache to use using --with-apxs, stopped

Traceback (most recent call last):
   File "test.py", line 857, in ?
   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:


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.


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

View raw message