py.test and py lib.notes

Wednesday, March 23, 2005

TITLE OF PAPER: py.test and the py lib
URL OF PRESENTATION: _URL_of_powerpoint_presentation_
PRESENTED BY: Holger Krekel

DATE: Wednesday, March 23, 2005
LOCATION: GWU Cafritz Conference Center, Grand Ballroom

{If you've contributed, add your name, e-mail & URL at the bottom}

(Presenting in Keynote, so he's cool already.. :-))

Testing and Python

 * automatically testing python programs is a honking great idea, let's do more ofit !
 * Unfortunately, Python projects have rather disparate tests tools and "runners"
 * Pythoneers deserve better than the classical

The reason for py test is that unittest was not easy to extend and lead to him to create it

What is py.test

  * py.test is an external project idnependent tool which
    * automatically and iternatively collects tests from dirctories, files, modules and classes
      * has extensive debugging aid
      * interacts with project-specific configuration to alter the ocllection and test execution process, including adding new command line options
      * is flexible enough to allow running PyPy's tess on a different virtual terminal
py.tests features (1)

  assert with assert statement
  automatic collection of tests on all levels
  testing starts immediately
  generative tests: yielding more user-defined tests
  specify different python versions / executables
  non nterference with cmd line utilities
py.text features (2)

  debug with the print statemnt
  order of runing tests as they appear in the files
  useful trace backs, e.g. recursion detection
  Manages test state across modules, classes and methods
  it has documentation

py.tet aserting the obvious
The ide of "y.test" and the py lib in general is "no API is the best API".  For etesting this e.g. means reusing the assert statement.

  def f():              
     return 23
  def test_f():
    assert f() == 42

mangeing test state

setup and teardown resources at various levels

def setup_module(mod):
  mod.testfile = ...
class TestSomething:
  def setup_class(cls):
    cls.resource = ...
  def setup_method(self, method):
Generative tests
the easiets "non-api" way to extend the collection process is with generators wihcih allow to produce more tests on-the-fly

def func(arg1, arg2):
  assert arg1 == arg2 * 2
def test_more():
  for x,y in ((1,2), (2,3), (3,3)

Creative creation of tests using generators which 'yield' test functions and expected values

it's nice when it fails

py.test offers a number of helpful debugging features
  very usefule tracebacks
  isoloating print statements per test
  showing locals
  dropping int pdb on failures
  session: rerunning continuious failing test only
  --nomagic -- nocapture may be your friend :)

Configurable framework - knows about the test set size, can run just the failing tests as you edit your code until 0 tests fail.

itneractive example

he is on a live python session and running a failure demo program
  testing mode is run inprocess so it's running in the same session that py.test is running in
  showing examples of a testing config setup that allows for local changes to the test configuration
  he is showing in the output that actual test being run and also the traceback and codes on the left showing the state of the test
  he is showing an example that py.test is re-interpreting the code and results and adding to the output a note or marker on what the failure was inline so you can see it without having to enter the code editor

py.test --pdb
  when the failure happens you will enter pdb where you can debug

py.test near-future plans

py.test is to become a unified python testing tool
  refining and documenting project config
  gui/html reporting
  distributing tests across platforms
  releasing it...

on to the py lib

py.test is part and makes use of the py lib:
  py.path: local and subversion filesystem objects
  py.execnet: ad-hoc distribution of programs
  py.magic: provides e.g. greenlets
  py.code: nicifying python introspection
  py.xml: providing simple xml/html object generation

runs on python 2.2 onwards

goals of the py.lib
  provide a high level and integrated standard set of serives and methods useful for development
  first step: project independent and flexible tesing tools
  experiment with improving python library development e.g. via explicitly exporting names
  repackageing and extending python's standard library e.g. offering a unified Path objec for both local and remote access

py lib hightligh: ad-hoc distributing programs
  py.execnet provides a smple mechanism to execute arbitrary code in remote locations
  communication between local andremote sits happen through channels

showing a live example of py.execnet

  >>> import py
  >>> py.execnet.
  * <typ>SoccketGeateway(2)
  >>> py.execnet.SshGateway('')
  <SshGateway 1/1 (1 active channels)>
  >>> ssh=_
  >>> ssh.remote_exec("imprt sys ; channel.send(sys.version_info)")
  <Channel id=3 open>
  >>> c=_$
  >>> c.receive()
  (2, 3, 5, 'final', 0)
  >>> ssh.remote_exec("import os; channel.send (channel.receive()+1)")
  <Channel ide=5 open>
  >>> c=_
  >>> c.send(41)
  >>> c.receive()
  >>> c
  <Channel ide=5  closed>
  >>> c.receive()
  Traceback happend because the channel is closed
  started showing other process's that are also running and showed how to connect to another computer to show that it is distributed

  >>> ssh.remote_exec("""
    .... while 1:
    ....    fn = channel.receive()
    ....    channel.send(open(fn).read())
    .... """)
    shows a huge listing of filenames that were on the remote system
future (and thanks for) fish

finalize design of py.test and include doctests
refine consistency and actually release the damn ting
expose remote Path-Over-Ssh objects
try improve windows-interactions

py lib info

the py lib is driven by Holger Krekel and Armin Rig

Q. is the py.test all python
A. it is complete python but there is a directory of c extensions that could be compiled if you have access to a compiler

Q. do you use py.test for acceptance testing or do you limit yourself to unit tests
A. to be honest he can't follow the whole seperation of unittests from acceptance testing - the example he showing is an example of testing the documentation that uses a generator that generates the rest test function to see if the docs are generated properly

REFERENCES: {as documents / sites are referenced add them below}
py.test at <>
py lib at <


CONTRIBUTORS: {add your name, e-mail address and URL below}
Nick Bastin ( <>
Mike Taylor (he wrote most of it)

E-MAIL BOUNCEBACK: {add your e-mail address separated by commas }

A headline (like a field in a database) will be CAPITALISED
    This differentiates from the text that follows
A variable that you can change will be surrounded by _underscores_
    Spaces in variables are also replaced with under_scores
    This allows people to select the whole variable with a simple double-click
A tool-tip is lower case and surrounded by {curly brackets / parentheses}
    These supply helpful contextual information.

Copyright shared between all the participants unless otherwise stated...