You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by Jim Gallacher <jp...@jgassociates.ca> on 2006/10/02 23:01:28 UTC
New mod_python unittest framework
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
Re: New mod_python unittest framework
Posted by Jim Gallacher <jp...@jgassociates.ca>.
Graham Dumpleton wrote:
> 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.
+1
> 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.
_get_version() is pretty much the same as in the old test.py. I think
the problem may be a stray "continue" statement in the prior code block,
and with apache 1.3.33 it's picking up an extra blank line. So we've
found 2 things - bug in the new code, and a possible bug in the old code.
Finding the correct apxs and apache should certainly be more robust.
Currently we use the output of configure, but I'd like to remove that
dependency so that the test framework will work without configuring or
compiling mod_python.
> 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.
Yep. As I said, only tested with python 2.4.
> 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?
Yes.
> 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.
+1
How do you feel about the overall concept and design?
Jim
>
> 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
>
Re: New mod_python unittest framework
Posted by Graham Dumpleton <gr...@dscpl.com.au>.
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