Mailman 3 August 2010 - pytest-dev

[py-dev] py.test api - Running tests in a module object?
by Sridhar Ratnakumar Nov. 29, 2010

Nov. 29, 2010

I am trying to run py.test on a given module object dynamically. mod = __import__('company.foo.somemod') py.test.run(mod) A quick glance in the py.test source doesn't seem like a trivial thing. IPython introspection did not give me any clue either. Is there a way to do this at all? I did try py.test.cmdline.main(['...']), but that accepts only file path, not the Python module object itself. -srid

2 5

[py-dev] Advanced assert equal
by Floris Bruynooghe Sept. 22, 2010

Sept. 22, 2010

Hi Ever since unittest grew it's .assertSequenceEqual() and .assertMultilineEqual() I've been jealous of it. So this weekend I've looked into the py.test code and made an attempt at getting this into my favourite testing tool. The attached patch makes compare equal a special case and checks if the two arguments to it are both a list, text or dict and tries to generate a nicer explanation text for them. The patch is more like a proof of concept then a final implementation, I may have done some very strange or silly things as I'm not familiar with the code. It would be great to get feedback, both on the general concept and the actual implementation (particularly note the way I had to hack _format_explanation() in assertion.py). Some of the rough edges I can think off right now: (i) no idea how comparisons and nested calls work together, (ii) no attempt is made to limit the output from difflib so the screen doesn't get flooded. There's probably many more. I hope this can be useful Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

3 10

[py-dev] [proposal] extended information collection
by Ronny Pfannschmidt Sept. 1, 2010

Sept. 1, 2010

Recently i noticed a new need. The collecting/asserting various kinds of data during a testrun. I noticed the following (partially hpyothetical) cases in various projects * pip records file changes to the virtualenv it makes for testing * pypy records jit compile results/dumps * jinja2 should record asts and the compile results of templates it tests * the logcapture extension * the build-in io captureing i think i would be helpful/practical to have a common way to record those things and navigate them in extended test reporters adding propper timing information to lines/data could help even more (for having a common timeline of different event sources) since this topic is rather hard to manage i hope for some dicussion on the needs others see, as well as if/how this could add more to the testing regards Ronny

2 1

[py-dev] py.test doesn't like functools.partial wrappers
by Florian Bauer Sept. 1, 2010

Sept. 1, 2010

Hi all, I'm trying to make an existing testsuite py.test compatible. At the moment, we use nose as test runner. I stumbled upon the following (simplified example). from functools import partial def forall_cases(cases): def decorate(testfn): def gen(): for case in cases: description = case[0] args = case[1:] func = partial(testfn, *args) func.description = description yield func, gen.__name__= 'test_%s_' % testfn.__name__ # # inject the generator into the module testfn came from # gen.__module__ = testfn.__module__ return gen return decorate @forall_cases([['case1', 1, 1], ['case2', 2, 2],['case3', 3, 4]]) def test_equal(a, b): assert a == b If I run this with nosetests, I get 3 test cases, 2 pass and 1 fail. py.test tries to call inspect.getsource on the partial object, which results in a TypeError: $ py.test -v ... INTERNALERROR> INTERNALERROR> object = <functools.partial object at 0x00F019C0> INTERNALERROR> INTERNALERROR> def getfile(object): INTERNALERROR> """Work out which source or compiled file an INTERNALERROR> object was d efined in.""" ... INTERNALERROR> > raise TypeError('arg is not a module, class, method, ' INTERNALERROR> 'function, traceback, frame, or INTERNALERROR> code obje ct') INTERNALERROR> E TypeError: arg is not a module, class, method, function, traceback, frame, or code object INTERNALERROR> INTERNALERROR> object = <functools.partial object at 0x00F019C0> INTERNALERROR> INTERNALERROR> c:\Python26\lib\inspect.py:418: TypeError This seems to be a documented limitation of inspect.getsource (functools.partial returns a partial object, not a function). I can fix this by replacing functools.partial with code given as roughly equivalent in the python documentation: def partial(func, *args, **keywords): def newfunc(*fargs, **fkeywords): newkeywords = keywords.copy() newkeywords.update(fkeywords) return func(*(args + fargs), **newkeywords) newfunc.func = func newfunc.args = args newfunc.keywords = keywords return newfunc But I was certainly not expecting this. The default behavior of py.test is even more puzzling, as it fails silently: fbauer@MN-ENG-LT-FB ~/My Documents/Software/pytestbug1 $ py.test ============================= test session starts ============================= platform win32 -- Python 2.6.5 -- pytest-1.3.3 test path 1: c:\docume~1\fbauer\My Documents\Software\pytestbug1 test_case.py .. In my actual code, the forall_cases decorator lives in a utils module. Is there a conditional flag that can tell me whether I'm running under py.test? Then I could start experimenting with parametric tests using funcargs, while keeping the test suite runnable with nose at the moment. I still have a bug in the test suite, as I have tests passing under nose that fail under py.test... Best regards, Florian _______________________________________________________________________________________ Dialog Semiconductor GmbH Neue Str. 95 D-73230 Kirchheim Managing Director: Dr. Jalal Bagherli Chairman of the Supervisory Board: Gregorio Reyes Commercial register: Amtsgericht Stuttgart: HRB 231181 UST-ID-Nr. DE 811121668 Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

3 3

[py-dev] Greenlet
by Richard Tew Sept. 1, 2010

Sept. 1, 2010

Hi, In the past, I believe py included the greenlet c extension source code. I am not sure that you do anymore, or how this affects you now that it may only relate to older releases of your source code, but I would like to mention that the py library as far as I can tell effectively relicensed Python licensed code under the MIT license. Please correct me if I am wrong. http://codespeak.net/svn/py/branch/py-compat-2.5.2/py/c-extension/greenlet/ The files sourced from Stackless presumably by Christian for use with Armin in the creation of greenlet, were contributed to Stackless and subject to contributions from multiple parties, under the Python license. I am pretty sure that Christian did not, and was more than likely unable to relicense them to the MIT license on behalf of those parties. Anyway, I've brought this up with the greenlet project here: http://bitbucket.org/ambroff/greenlet/ And since that was spun off the py lib, I thought I would mention it here. Cheers, Richard.

3 2

[py-dev] New issue 115 in py-trunk: Catch-all exceptions don't make an exception for GeneratorExit
by issues-noreply＠bitbucket.org Aug. 15, 2010

Aug. 15, 2010

--- you can reply above this line --- New issue 115: Catch-all exceptions don't make an exception for GeneratorExit http://bitbucket.org/hpk42/py-trunk/issue/115/catch-all-exceptions-dont-mak… Floris Bruynooghe / flub on Sun, 15 Aug 2010 16:29:43 +0200: Description: Hi pylib seems to often use {{{ try: ... except (KeyboardInterrupt, SystemExit): raise except: ... }}} However this currently misses GeneratorExit and might miss other exceptions which don't (and shouldn't) inherit from Exception in the future. However the hierarchy only got rearranged in python 2.5 and GeneratorExit was only present since 2.5. So maybe this can't be solved until 2.4 is no longer supported. Regards Floris Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0

[py-dev] Generic funcarg hook
by Floris Bruynooghe Aug. 13, 2010

Aug. 13, 2010

Hi I was talking to ronny on IRC about wanting a generic funcarg hook and he asked me to post my use case here as you are still thinking about the API for it. Since there is no generic funcarg hook now this is how I currently create the tests: def pytest_funcarg__tdata(request): fname = os.path.join(DATADIR, requst.function.__name__+'.ext') with file(fname) as fd: obj = fd.read() return obj def test_spam(tdata): assert func_under_test(tdata) == 'foo' def test_eggs(tdata): assert func_under_test(tdata) == 'bar' Before I started writing it this way I was looking for a generic funcarg hook since I think this would have been clearer if I could have used "spam" and "eggs" as funcargs and still create the object for them from one function rather then having to spell it out for each one. So I'm hoping that in a future version you might add an API to do allow something like this. -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org

3 5

[py-dev] survey results unittest/py.test/nose/...
by holger krekel Aug. 11, 2010

Aug. 11, 2010

Hi all, came across this activestate link which recently surveyed usage of test automation frameworks: http://www.activestate.com/blog/2010/07/survey-says-selenium-nose-most-popu… I am pleasantly surprised to find py.test come ahead of nose and don't quite get the title and the summary which seem to indicate otherwise. Probably I am missing something? best, holger

1 0

[py-dev] pytest-cov
by meme dough Aug. 10, 2010

Aug. 10, 2010

Hi, The --cov option is now filesystem paths as that should be how it will work with the upcoming source option from coverage. Help text updated. Warning when nothing to report on. Reports on generation of html, xml and annotated source. Minimised imports. Haven't moved DistMaster / DistSlave yet as found easier for minimising imports if not in pytest-cov, may make a separate module there, will consider further. :)

2 1

[py-dev] New issue 114 in py-trunk: cmdline(..) uses wrong program name
by issues-noreply＠bitbucket.org Aug. 5, 2010

Aug. 5, 2010

--- you can reply above this line --- New issue 114: cmdline(..) uses wrong program name http://bitbucket.org/hpk42/py-trunk/issue/114/cmdline-uses-wrong-program-na… Sridhar Ratnakumar / srid on Fri, 6 Aug 2010 01:46:12 +0200: Description: I am invoking py.test via py.test.cmdline(). When there is an error in command line, the following is printed: {{{ usage: boa [options] [file_or_dir] [file_or_dir] [...] boa: error: no such option: --junitlxml }}} "boa" is the name of *my* program, which py.test.cmdline() is stealing. Responsible: hpk42 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0