Mailman 3 October 2009 - pytest-dev

[py-dev] py.test : setup / teardown at the directory level
by Philippe Fremy April 16, 2010

April 16, 2010

Hi, I was wondering if there is a possibility to have or emulate setup/teardown method for an entire directory of tests ? I have an expensive setup/teardown method, which I share through about 10 modules, each with about 20 tests. I would save time if I could do the setup/teardown just for that directory. cheers, Philippe

3 9

Re: [py-dev] using funcargs for setup/teardown
by holger krekel Nov. 10, 2009

Nov. 10, 2009

Hi Frederik! On Sun, Oct 25, 2009 at 14:00 +0000, Frederik Dohr wrote: >> It contains many examples and also a reference for the API. I consider >> splitting the two aspects. > > That's probably a good idea. > >> If py.test did some basic logging that shows which user code is >> invoked when (e.g. test function, setup functions, funcarg >> factories, plugin or conftest hooks ...) it would make such >> help-examples smaller and more focused. >> [...] >> Below is a try at explaining funcargs from a "read-source" perspective. >> > > Unfortunately, I cannot relate to this - likely due to my overall > ignorance when it comes to funcargs. > > However, I've finally figured out why I'm having such a hard time > warming up to funcargs: They go way beyond the minimalist simplicity > that made me switch to py.test in the first place. > (I realize there's some Magic to py.test's internals, but that doesn't > surface in the API.) > > Funcargs seem like a departure from this principle. > I understand that some situations demand such complexity, so I'm not > arguing against funcargs in general - but for my part, I've managed to > keep it simple so far. I don't want to argue "simplicity" but let me state my perspective and considerations - maybe they shed some light on why i consider the funcargs approach more powerful: test functions are Python functions. Python functions need certain objects to run. Why now use degraded Python functions for tests, i.e. ones that never receives parameters? This implies having to call magic methods for setting up objects in global namespaces or 'self' attributes - which not only makes the test harder to understand and refactor IMO. It also means that setups for different aspects, e.g. mocking a database and mocking a web service intermingle in one setup area whereas funcarg factories allow to keep such setup aspects totally separate and reuseable across the whole test suite. > All of this is to say that I'm happy enough with this for setup and > teardown*, but I'm probably the wrong person to comment on anything > beyond that. i disagree also here a bit - rather appreciate your feedback :) cheers, holger

2 5

[py-dev] using funcargs for setup/teardown
by Frederik Dohr Nov. 6, 2009

Nov. 6, 2009

In a brief conversation with Holger today, I confessed that for a long time I couldn't bring myself to properly read up on funcargs. While I appreciate the obvious efforts that have gone into creating the comprehensive documentation*, it did seem just a little intimidating. (Also, I generally prefer reading code to reading prose.) Anyway, I finally played around a bit with funcargs, and it actually turned out to be fairly easy to get started: http://gist.github.com/214495 While those code samples are certainly not perfect, I figured it might be useful to share this naive quickstart approach with the class. I'll need to do more reading to assess whether or how this fits into the existing documentation though. -- Fred * http://codespeak.net/py/dist/test/funcargs.html

2 6

Re: [py-dev] Log to a file
by Simon Nov. 4, 2009

Nov. 4, 2009

On 16/10/2009, at 21:23 , holger krekel holger-at-merlinux.eu |py-dev + execnet-dev| wrote: > On Thu, Oct 15, 2009 at 23:15 -0000, Simon wrote: >> On 16/10/2009, at 04:31 , Maciej Fijalkowski fijall-at-gmail.com |py- >> dev + execnet-dev| wrote: >> >>> On Wed, Oct 14, 2009 at 9:56 PM, Simon <5kycsae02(a)sneakemail.com> >>> wrote: >>>> Hi! >>>> >>>> I would like to capture the verbose output of test runs to a file >>>> so that the debug is captured to a file regardless of whether the >>>> test failed or when the test is not running to completion. >>>> >>>> Is there an easy way of doing this via a command line option, or >>>> should I be perhaps modifying the resultlog plugin or something >>>> similar? >>>> >>>> Thanks, >>>> >>>> Simon >>> >>> You know about py.test -s right? >>> >>> Cheers, >>> fijal >> >> Sorry, I wasn't particularly clear. >> >> We generally run our tests with the -v option which is fine, which >> produces a level of output suitable for our general day to day use. >> >> However we would also like to log the complete (-s) output to a file >> in the background. So that if at some point in the future we need to >> go through the detailed output, it is available. >> >> We'd also like this to happen in such a way that if the tests were to >> hang or hard crash halfway through, we still have the debug log. >> >> Any ideas? > > I am not completely sure how to best implement it. Maybe extend the > "--capture" option to specify a filename. A naive implementation > would > only produce the test output though, not meta-information like test > name > or traceback. Maybe a bit tricky to get this working for dist- > testing like > "-n 3" but that's probably true for any impl idea for this feature. > > what do you think? > > Capturing is done via code in the _py/test/plugin/pytest_capture.py > and > in _py/io/capture.py (py-trunk references) - not completely trivial > code > because it works hard to play nicely with tests/apps using the > std logging module which assumes ownership of sys.stdout/stderr > stream. > Do you feel like giving it a try? > > I plan for a 1.1 beta1 soon so it could be available soon. > > best, > holger Hi Holger, I started looking into this a bit but ran into a problem when I started to probe the py.io module. I tried running the py.io examples on the website <http://codespeak.net/py/dist/io.html > but when I run the py.io.StdCaptureFD example, python dies on the second line: stakita@okum:~$ python Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. History restored: /auto/home/stakita/.pyhistory, Max Length: 500 >>> import py, sys >>> capture = py.io.StdCaptureFD() stakita@okum:~$ My guess is that an exception is being thrown, but the captured sys.stderr descriptor is not passing any meaningful traceback. I tried wrapping the call in try/except, but that didn't seem to help. On the positive side, the problem appears to be quite reproducible. Any ideas on what is going on here? Regards, Simon Sysinfo: stakita@okum:~$ uname -a Linux okum 2.6.28-15-generic #51-Ubuntu SMP Mon Aug 31 13:33:16 UTC 2009 i686 GNU/Linux stakita@okum:~$ python Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. History restored: /auto/home/stakita/.pyhistory, Max Length: 500 >>> import py >>> py.version '1.0.2'

2 3

[py-dev] is anybody seeing this kind of explosion?
by Samuele Pedroni Oct. 29, 2009

Oct. 29, 2009

py lib trunk is exploding this way for me right now, I removed pyc files btw pedronis@vitaly:~/scratch/jskit-nightly$ /u/pedronis/vjskit/bin/python py-trunk/py/bin/py.test --help inserting into sys.path: /u/pedronis/scratch/jskit-nightly/py-trunk Traceback (most recent call last): File "py-trunk/py/bin/py.test", line 3, in <module> py.cmdline.pytest() File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/cmdline.py", line 11, in main config = py.test.config File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line 56, in __getattr__ result = importobj(modpath, attrname) File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line 23, in importobj module = __import__(modpath, None, None, ['__doc__']) File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/config.py", line 2, in <module> from _py.test.conftesthandle import Conftest File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/test/conftesthandle.py", line 2, in <module> defaultconftestpath = py.path.local(__file__).dirpath("defaultconftest.py") File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/path/local.py", line 135, in __new__ elif isinstance(path, py.builtin._basestring): File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line 56, in __getattr__ result = importobj(modpath, attrname) File "/u/pedronis/scratch/jskit-nightly/py-trunk/_py/apipkg.py", line 24, in importobj return getattr(module, attrname) AttributeError: 'module' object has no attribute '_basestring'

2 1

[py-dev] New issue 58 in py-trunk: py.test broken with use of multiprocessing.Process
by issues-noreply＠bitbucket.org Oct. 23, 2009

Oct. 23, 2009

New issue 58: py.test broken with use of multiprocessing.Process http://bitbucket.org/hpk42/py-trunk/issue/58/pytest-broken-with-use-of bluebird75 on Fri, 23 Oct 2009 10:40:28 +0200: Description: The following program clearly highlights the problem: {{{ #!python import os from multiprocessing import Process def do_task1(): print 'task1: pid=%d' % (os.getpid()) class TestProcess: def test_p1( self ): print 'test_p1: pid=%d' % os.getpid() p = Process( name='p1', target=do_task1 ) p.start() p.join() }}} Philippe@pc-philippe /cygdrive/d/work/elc-dev/tmp $ py.test -s ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=3920 ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=3344 ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=208 ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=3364 ============================= test session starts ============================= python: platform win32 -- Python 2.6.1 test object 1: d:\work\elc-dev\tmp test_process.py test_p1: pid=536 ... As you can see, Process() is restarting py.test instead of starting the target function. This is on windows XP, python 2.6.1 . 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] pending py.test-1.1.0b1 / advanced skipping
by holger krekel Oct. 22, 2009

Oct. 22, 2009

Hi all, Next week I'd like to package a 1.1b1 release working well with CPython 2.4-3.1, pypy and Jython. My intention is for it to be major cleanup release, backward compatible but deprecating old stuff. It will also introduce a few new features and refinements, among them generalized skipping: http://codespeak.net/py/trunk/test/plugin/skipping.html If you have any feedback or comments on this, i am happy to hear them. Bitbuckets py-trunk repo has the working code - and i am also hanging around on #pylib on freenode usually. cheers, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu

1 0

[py-dev] New issue 57 in py-trunk: looponfail traceback on unexpected pass of a xfail test
by issues-noreply＠bitbucket.org Oct. 20, 2009

Oct. 20, 2009

New issue 57: looponfail traceback on unexpected pass of a xfail test http://bitbucket.org/hpk42/py-trunk/issue/57/looponfail-traceback-on-unexpe… RonnyPfannschmidt on Tue, 20 Oct 2009 17:15:59 +0200: Description: trace on http://paste.pocoo.org/show/145976/ 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] New issue 56 in py-trunk: Problems testing modules in namespace package
by issues-noreply＠bitbucket.org Oct. 19, 2009

Oct. 19, 2009

New issue 56: Problems testing modules in namespace package http://bitbucket.org/hpk42/py-trunk/issue/56/problems-testing-modules-in-na… cdent on Mon, 19 Oct 2009 18:14:59 +0200: Description: When using namespace_packages if I am testing a new module in a namespace that is already installed into sys.path (e.g. an egg in that namespace is already on sys.path) then the new module fails to import when running the test file against py.test. If I run the same test file with python (and have the test executed) all goes well and the correct code is imported, and the test passes as expected. While narrowing this down I created a new namespace package and tested it in place (before installing it as an egg). That first test worked fine. I then created a second module in the same namespace and tested it before installing the first module. That tested fine. I then installed the first module. Subsequent tests of the second module failed. I'm in Python 2.6.1, py 1.0.2 on OS X 10.6.1 I have attached a tarball which ought to demonstrate this situation. Inside the tarball are two directories: test.one and test.two. Both contain modules which are destined for the test1234 namespace. As they stand the single test in test dir in each should run just fine. However if 'python setup.py install' is run in the test.one directory, installing test1234.one as egg, the test in test.two will fail to 'from test1234.two import two' (assuming that things don't work). At first glance this makes me think "oh namespace_packages" are yucky, but if you run 'python test/test_two.py' things work fine... Happy to do any additional digging about as required. Thanks. A little more cookbooky on the tarball: * tar zxvf testme.tar.gz * cd testme/test.one * py.test test # expect success * cd ../test.two * py.test test # expect success * cd ../test.one * sudo python setup.py install # install egg * cd ../test.two * py.test test/test_two.py # except failure "E ImportError: No module named two" * python test/test_two.py # expect success 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] generalized skipping / xfail
by holger krekel Oct. 16, 2009

Oct. 16, 2009

Hi all, i've just written docs and ported bits of py.test's own test suite to the new "generalized skipping" feature. With it one can mark test functions, classes or modules for conditional skipping ... see here for more details and examples: http://codespeak.net/py/trunk/test/plugin/skipping.html feedback very welcome. best, holger -- Metaprogramming, Python, Testing: http://tetamap.wordpress.com Python, PyPy, pytest contracting: http://merlinux.eu

2 1