test suite support
Hello! I am using distutils that come with python2.2 to build and install the module pygsl (http://pygsl.sourceforge.net). In order to ensure quality I started to collect tests with unittest. In analogy to the automake feature "make test" or "make check" I would like to have a standard test command for setup.py . For test purposes, I have developed this script: ### Begin import sys import os.path import distutils.sysconfig import distutils.util import unittest my_path=os.path.dirname(os.path.abspath(sys.argv[0])) my_version=distutils.sysconfig.get_config_var('VERSION') build_lib_path=os.path.join(my_path,"build","lib.%s-%s"%(distutils.util.get_platform(),my_version)) test_path=os.path.join(my_path,"tests") sys.path.insert(-1,build_lib_path) sys.path.insert(-1,test_path) from histogram_test import * from rng_test import * from const_test import * if __name__ == "__main__": unittest.main() ### End It adds the temporary build directory and the test suite directory to the module search path. After that it imports all test cases and executes them. So I can test my modules without installing it to the site-packages. Maybe similar code could be included in a test command. Could you tell me the correct way to get build_lib_path ?
Achim Gaedke wrote:
I am using distutils that come with python2.2 to build and install the module pygsl (http://pygsl.sourceforge.net). In order to ensure quality I started to collect tests with unittest.
In analogy to the automake feature "make test" or "make check" I would like to have a standard test command for setup.py .
Why not add this as new "test" command to distutils ?! It could have options which programmers can then set in order for the command to find the test suits to run, e.g. python setup.py test I'd suggest to use an approach similar to what build_ext and the Extension class have to offer (in terms of code design). -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
"M.-A. Lemburg" schrieb:
Why not add this as new "test" command to distutils ?! It could have options which programmers can then set in order for the command to find the test suits to run, e.g.
python setup.py test
I'd suggest to use an approach similar to what build_ext and the Extension class have to offer (in terms of code design).
I will try to do so next week, but I feel impelled to read a lot of distutils soure.
From: "M.-A. Lemburg" <mal@lemburg.com>
Why not add this as new "test" command to distutils ?! It could have options which programmers can then set in order for the command to find the test suits to run, e.g.
python setup.py test
I'd suggest to use an approach similar to what build_ext and the Extension class have to offer (in terms of code design).
I've used the following code which was posted by Berthold Höllmann to this list with good success in several of my setup scripts... Thomas class test(Command): # Original version of this class posted # by Berthold Höllmann to distutils-sig@python.org description = "test the distribution prior to install" user_options = [ ('test-dir=', None, "directory that contains the test definitions"), ('test-prefix=', None, "prefix to the testcase filename"), ('test-suffixes=', None, "a list of suffixes used to generate names the of the testcases") ] def initialize_options(self): self.build_base = 'build' # these are decided only after 'build_base' has its final value # (unless overridden by the user or client) self.test_dir = 'tests' self.test_prefix = 'test_' self.test_suffixes = None # initialize_options() def finalize_options(self): import os if self.test_suffixes is None: self.test_suffixes = [] pref_len = len(self.test_prefix) for file in os.listdir(self.test_dir): if (file[-3:] == ".py" and file[:pref_len]==self.test_prefix): self.test_suffixes.append(file[pref_len:-3]) build = self.get_finalized_command('build') self.build_purelib = build.build_purelib self.build_platlib = build.build_platlib # finalize_options() def run(self): import sys # Invoke the 'build' command to "build" pure Python modules # (ie. copy 'em into the build tree) self.run_command('build') # remember old sys.path to restore it afterwards old_path = sys.path[:] # extend sys.path sys.path.insert(0, self.build_purelib) sys.path.insert(0, self.build_platlib) sys.path.insert(0, self.test_dir) # build include path for test for case in self.test_suffixes: TEST = __import__(self.test_prefix+case, globals(), locals(), ['']) try: tested_modules = TEST.tested_modules except AttributeError: tested_modules = None else: from code_coverage import Coverage coverage = Coverage(modules=tested_modules) sys.settrace(coverage.trace) TEST.test() if tested_modules is not None: # reload tested modules to get coverage of imports, etc. for name in tested_modules: module = sys.modules.get(name) if module: reload(module) sys.settrace(None) sys.stdout.write("code coverage:\n") coverage.write_results(sys.stdout) # restore sys.path sys.path = old_path[:] # run() # class test
On Tue, 15 Jan 2002 19:46:41 +0100, "Thomas Heller" <thomas.heller@ion-tof.com> wrote:
From: "M.-A. Lemburg" <mal@lemburg.com>
Why not add this as new "test" command to distutils ?! It could have options which programmers can then set in order for the command to find the test suits to run, e.g.
python setup.py test
I'd suggest to use an approach similar to what build_ext and the Extension class have to offer (in terms of code design).
I've used the following code which was posted by Berthold Höllmann to this list with good success in several of my setup scripts... [...]
I strongly support *any* form of a test command. I think that this is very important, to encourage people to provide test suites with their distributions. The problem, to some extent, is that there are too many "home-grown" solutions. We just need one version, added to the "official" distribution. Can Thomas' version be added to CVS, so that it gets into Python 2.3? It's a real shame, in retrospect, that this didn't get done for 2.2. If not Thomas' version, then can someone provide a version? But this is very definitely a case where anything is better than nothing... Paul. (Sorry, I campaigned about this a long while ago, but I let it drop. I shouldn't have.)
I'd like to have unittest support, because it seems to me comfortable to unify testsuites and easy to adapt own existing tests, but I have not enough experience to write good code for this purpose. I suggest two changes to Thomas code: * Use unittest.main(module) for test execution and * prepend the build-directory used by build and build_ext to sys.path, so the new modules are found. That is important for c-code. Some links for unittest: Homepage: http://pyunit.sourceforge.net/ Python Docs: http://www.python.org/doc/current/lib/module-unittest.html Paul Moore schrieb:
On Tue, 15 Jan 2002 19:46:41 +0100, "Thomas Heller" <thomas.heller@ion-tof.com> wrote:
From: "M.-A. Lemburg" <mal@lemburg.com>
Why not add this as new "test" command to distutils ?! It could have options which programmers can then set in order for the command to find the test suits to run, e.g.
python setup.py test
I'd suggest to use an approach similar to what build_ext and the Extension class have to offer (in terms of code design).
I've used the following code which was posted by Berthold Höllmann to this list with good success in several of my setup scripts... [...]
I strongly support *any* form of a test command. I think that this is very important, to encourage people to provide test suites with their distributions.
The problem, to some extent, is that there are too many "home-grown" solutions. We just need one version, added to the "official" distribution.
Can Thomas' version be added to CVS, so that it gets into Python 2.3? It's a real shame, in retrospect, that this didn't get done for 2.2. If not Thomas' version, then can someone provide a version? But this is very definitely a case where anything is better than nothing...
Paul.
(Sorry, I campaigned about this a long while ago, but I let it drop. I shouldn't have.)
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
From: "Achim Gaedke" <Achim.Gaedke@uni-koeln.de>
I'd like to have unittest support, because it seems to me comfortable to unify testsuites and easy to adapt own existing tests, but I have not enough experience to write good code for this purpose.
I suggest two changes to Thomas code:
* Use unittest.main(module) for test execution and
I know about unittest, but don't use it any more. I've converted all my tests to Tim Peters' doctest. The test command I posted simply calls a test function, which can use doctest, unittest or whatever internally.
* prepend the build-directory used by build and build_ext to sys.path, so the new modules are found. That is important for c-code.
Thats what these lines are supposed to do: # extend sys.path sys.path.insert(0, self.build_purelib) sys.path.insert(0, self.build_platlib) Thomas
participants (4)
-
Achim Gaedke -
M.-A. Lemburg -
Paul Moore -
Thomas Heller