Mailman 3 November 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

[py-dev] ciss-0.1: code-centered issue tracking
by holger krekel Nov. 28, 2009

Nov. 28, 2009

Hi all, just released ciss-0.1, my attempt at (what i call) code-centered issue tracking. ciss is: - a command line tool for managing your ISSUES.txt - code-centered: associate issues to files in your project - extensible: assign tags for status/milestone/custom usage. - ueber-powerful issue editing: your text editor! - well tested (more tests than code) If that appeals to you somewhat, check it out: http://codespeak.net/ciss And in case you wonder, why i don't use pitz or ditz? For one, I don't want to edit my issues from an interactive Python prompt, sorry. Second, they create directories and pickle-files and whatnot - i just want to keep a plain text file for a number of projects and using a text editor and a nice cmdline tool is the fastest way i can imagine. Oh, and I do see use in web-based issue interaction but keeping issues close-to-code (tm) and easy-to-edit (tm) is just so much more fun. Besides, i believe 'ciss' could learn to round-trip with existing trackers. anyway, have fun, holger

2 1

[py-dev] py.test-1.1.1: compat fixes, setuptools-plugin registration
by holger krekel Nov. 24, 2009

Nov. 24, 2009

py.test/pylib 1.1.1: bugfix release, setuptools plugin registration -------------------------------------------------------------------------------- This is a compatibility fixing release of pylib/py.test to work better with previous 1.0.x test code bases. It also contains fixes and changes to work with `execnet>=1.0.0`_ to provide distributed testing and looponfailing testing modes. py-1.1.1 moreover introduces a new mechanism for registering plugins via setuptools. What is pylib/py.test? ----------------------- py.test is an advanced automated testing tool working with Python2, Python3 and Jython versions on all major operating systems. It has an extensive plugin architecture and can run many existing common Python test suites without modification. Moreover, it offers some unique features not found in other testing tools. See http://pytest.org for more info. The pylib provides local and svn filesystem Path objects installs some developer-oriented command line tools. See http://pylib.org for more info. thanks to all who helped and gave feedback, have fun, holger (http://twitter.com/hpk42) .. _`execnet>=1.0.0`: http://codespeak.net/execnet Changes between 1.1.1 and 1.1.0 ===================================== - introduce automatic plugin registration via 'pytest11' entrypoints via setuptools' pkg_resources.iter_entry_points - fix py.test dist-testing to work with execnet >= 1.0.0b4 - re-introduce py.test.cmdline.main() for better backward compatibility - svn paths: fix a bug with path.check(versioned=True) for svn paths, allow '%' in svn paths, make svnwc.update() default to interactive mode like in 1.0.x and add svnwc.update(interactive=False) to inhibit interaction. - refine distributed tarball to contain test and no pyc files - try harder to have deprecation warnings for py.compat.* accesses report a correct location

1 0

[py-dev] execnet-1.0.0 released
by holger krekel Nov. 24, 2009

Nov. 24, 2009

Hi all, execnet-1.0.0 (compared to 1.0.0b3) has bug fixes, new tested examples and introduces execnet.Group for managing a dynamic bunch of hosts. See the improved docs http://codespeak.net/execnet/ and below the changelog fragment. cheers, holger 1.0.0 compared to 1.0.0b3 -------------------------------- * introduce execnet.Group for managing gateway creation and termination. Introduce execnet.default_group through which all "global" calls are routed. cleanup gateway termination. All Gateways get an id through which they can be retrieved from a group object. * deprecate execnet.XYZGateway in favour of direct makegateway() calls. * refine socketserver-examples, experimentally introduce a way to indirectly setup a socket server ("installvia") through a gateway url. * refine and automatically test documentation examples

1 0

Re: [py-dev] 1.1.1 wishes, bugs?
by Laura Creighton Nov. 18, 2009

Nov. 18, 2009

In a message of Wed, 18 Nov 2009 11:53:31 +0100, holger krekel writes: >Hi, > >i shortly plan to put out a 1.1.1 fixing some small issues. >anything i should look at/consider for the release? >If it's small annoyances, just post here, no need >to open "issues". > >best, >holger Small annoyance: Have py.test --help print the message that --report=skipped is how to get more information about skipped tests. Laura

1 0

[py-dev] 1.1.1 wishes, bugs?
by holger krekel Nov. 18, 2009

Nov. 18, 2009

Hi, i shortly plan to put out a 1.1.1 fixing some small issues. anything i should look at/consider for the release? If it's small annoyances, just post here, no need to open "issues". best, holger

1 0

[py-dev] virtual namespace for plugins
by Frederik Dohr Nov. 12, 2009

Nov. 12, 2009

Holger and I had a conversation about virtual namespaces on IRC. We're using this to have a common namespace for plugins*, and Holger expressed interest in using this approach as well. The goal is to use a common package name (here: "foo") for multiple independent modules or packages ("alpha" and "bravo" - to be accessed as foo.alpha and foo.bravo, respectively). It's actually rather simple: The individual components must be contained in a directory named after the virtual namespace, with an __init__.py containing nothing but the following statement: __import__("pkg_resources").declare_namespace(__name__) To make Python aware of the local package (e.g. for running tests out of the repository), something like the following is required in a root-level __init__.py: path = os.path.abspath(VIRTUAL_NAMESPACE) sys.modules[VIRTUAL_NAMESPACE].__dict__["__path__"].insert(0, path) This is illustrated here: http://gist.github.com/231862 Disclaimer: I'm far from being an expert, just sharing what we've learned so far (it's an ongoing effort). -- F. * http://cdent.tumblr.com/post/216241761/python-namespace-packages-for-tiddly…

1 1

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] uploaded a 1.0.0b3
by holger krekel Nov. 9, 2009

Nov. 9, 2009

Hi all, just uploaded a new 1.0.0b3 of execnet. see below for the changelog. cheers, holger 1.0.0b3 -------------------------------- * fix EXECNET_DEBUG to work with win32 * add support for serializing longs, sets and frozensets (thanks Benjamin Peterson) * introduce remote_status() method which on the low level gives information about the remote side of a gateway * disallow explicit close in remote_exec situation * perform some more detailed tracing with EXECNET_DEBUG

1 0

[py-dev] unclean shutdown of py.test
by Gordon Wrigley Nov. 9, 2009

Nov. 9, 2009

Short form: I have a test that in some circumstances can't raise an exception, all it can do is call stuff. Currently it calls sys.exit, which is less than optimal. Is there a function or series of functions I can call to somewhat cleanly shutdown py.test in this situation. Longer form: First It is worth noting that we always run py.test with -x, I suspect that will have some bearing on what follows.. The application I'm testing calls a bunch of C code via ctypes. In the event of certain pathological failures that C code does an internal error operation equivalent to assert, i.e. print some stuff and then call exit. When this happens there is no way to unroll the C stack to get back to the calling python context and notify py.test of the failure. What I have managed to do is intercept the error, and from the intercept use ctypes callback functionality to call into a python handler. It would be nice if I could raise an exception there and use that to get back to the original python context, but ctypes doesn't support that, instead it captures, prints and discards the exception before returning to the C context. I have sent them an idea I have for how the exception could instead optionally be propagated past the C and back to python using setjmp / longjmp, but I'm not really hopeful that that will be a viable alternative. So what I would like to do is clean up py.test in the callback. My ideal outcome would be if I could do some small amount of stuff that would make py.test act as if it were exiting due to a failed test while running with -x. Is this line of approach at all possible? or does it violate the py.test structure too much to be workable? Gordon

2 4