Comparison of py.test and nose for Python testing

I happened upon this useful comparison of py.test and nose at the testing-in-python mailing list, by Kenny (theotherwhitemeat at gmail). He spent some time evaluating testing tools for Python with a focus on py.test and nose . This article is a reformat of his mailing list post. I assume no credit for the content. The list of references [1] … [13] is at the end of article.


  • parallelizable: threading + SMP support [3] [4]
  • better documentation: [1] [3]
  • can generate script that does all py.test functions, obviating the need to distribute py.test [1][10]
  • integrate tests into your distribution (py.test –, to create a standalone version of py.test [10]
  • can run nose, unittest, doctest style tests [1] [2]
  • test detection via globs, configurable [3]
  • test failure output more discernible than nose [3] [9]
  • easier, more flexible assertions than nose [8]
  • setup speed is sub-second different from nose, also test speeds can be managed via distribution (threads + SMP via xdist) [9] [11]
  • provides test isolation, if needed [9]
  • dependency injection via funcargs [10] [12] [13]
  • coverage plugin [11]


  • documentation concerns, this may be outdated [3]
  • parallelization issues [3] [8]
  • slightly faster than py.test [4] [11]
  • test detection via regex (setup in cmdline or config file) [3]
  • can run unittest, doctest style tests [1] [2]
  • cannot run py.test style tests [1]


  • test formats are so similar, that nose or py.test can be used without much consequence until you’re writing more exotic tests (you could swap with little consequence)
  • nose is sub-second faster than py.test in execution time; this is typically unimportant
  • community seems to slightly favor py.test



Scripting ssh and git securely with Python

Some programs such as SSH ask for password and key passphrase via TTY (rather than STDIN), which is not supported by Python’s subprocess.Popen() call – the otherwise recommended, convenient way or running programs in a separate process.

This issue also arises when using SSH and PKI keys with git, to secure communications with a git server without an username and password.

This example illustrates use of pty.fork() from Python stdlib to support communications with a child process via a tty (a pty, actually).

There’s also some more explanations on how pty.fork() works, from Stack Overflow. Furthermore, Paul Mikesell has written an extensive article on scripting SSH with Python.

Uploadify session workaround

Due to design of Flash that Uploadify uses, there is a known problem whereby the Flash component of Uploadify does not pass back the cookies. So things like sessions do not work as expected out-of-the-box.

Luckily, there’s a workaround: uploadify has a scriptData option that you can populate from the session cookie  (perhaps using a jQuery cookie plugin for convenience). The option value is then passed to the backend app, which can use it to switch to the proper session. For example as follows:

First, a small function to fetch the session id:

var sid = function () {
   return {'sessionid':$.cookie('sessionid')}

Then, as part of the Uploadify initialization, set scriptData to pass the return value:

$(document).ready(function() {
     'uploader'  : '/uploadify/uploadify.swf',
     'script'    : '/upload_files',
     'scriptData': sid(), // <--- our function

This is just an incomplete example; for the rest of the options you want to initialize Uploadify with, see Uploadify docs.
As for backend processing, scriptData comes in as regular POST variables. I was building a simple Django app when encountering this problem, so here’s what I did to fetch the session id and switch to another Django session using it.

# get session id that was passed in via scriptData
sid = request.POST['sessionid']

# Switch to another session by triggering the
# SessionStore session loading machinery, using
# the proper session id that we passed in from
# Uploadify.
session = request.session

That’s all.