[portland] Meeting notes: August 11, 2009 - optparse, and testing in a Python world
igal at pragmaticraft.com
Wed Aug 12 05:35:03 CEST 2009
We had our first meeting at the new venue.
* WebTrends for providing the meeting space: http://www.webtrends.com/
* Emma for providing pizza: http://www.myemma.com/
* Volunteers for bringing beer
1. Michelle Rowley presented optparse, the module of the month
* "optparse" provides a powerful command line option parser. You use
it in programs that need to accept command line options, and it
helps parse the arguments, validate them and display errors, and
even show help for the program.
* Reference and tutorial: http://docs.python.org/library/optparse.html
2. Adam Lowry presented "Testing My Patience", discussing testing in Python
* Unit Testing helps ensure the correctness of a small piece of
code, like a method or class.
o "unittest" is a simple way to write tests as a series of
methods in a single file. It is part of the Python standard
o "py.test" is an older, simpler tool for running a series of
tests that are in their own files or documentation tests
sprinkled throughout code. Documentation:
o "nosetests" is a newer, more powerful tool for running a
series of tests that are in their own files or documentation
tests sprinkled throughout code. It has nice features like
being able to write plugins surrounding tests to reduce
duplication, distribute execution across machines, etc. It
is part of the Python standard library and is generally
preferred to "py.test". Documentation:
o "doctest" lets you write simple tests within the
"""documentation""" strings of your methods. In addition to
just unit testing, these also help ensure that your
documentation is correct and put your tests are near the
code. However, making use of these is tricky because you
must figure out ways to setup objects and represent objects
-- which you can do by writing nosetests plugins that wrap
test methods, e.g., setup and rollback a database
* Terms for faking it
o "Mocks" are fake objects used for testing. E.g., an object
pretending to be a User class.
o "Stubs" are real objects with parts replaced for convenience
of testing. E.g., a normal User class with the "first_name"
* Mocking and stubbing tools
o "Mock" by Michael Foord provides decorators for test methods
that temporarily replace specified methods elsewhere in your
code. Documentation: http://www.voidspace.org.uk/python/mock/
o "Mox" by Google provides a way to temporary way to alter an
object's methods within your test. This makes it easier to
express many behaviors, but unfortunately the code is
written using Google's weird coding style and is 4X more
verbose than RSpec, a Ruby library that uses a similar approach.
* Integration and functional testing
o These let you test multiple things at once and how multiple
pieces work together. These are trickier to get started with
because each application's stack is different and needs a
different way to setup and teardown.
o A good way to provide the setup/teardown is to use
package-level nosetests, e.g., setup: drop the database,
create a fresh one, start an application server; teardown:
o If you're using a framework (e.g., Django, TurboGears, etc),
you should try to use it's testing system to make this easier.
o "twill" is a simple language to simulate a web browser, and
offers commands like "go $url", "formvalue password
$password" and "submit". You point this at a web application
and can test it. Documentation: http://twill.idyll.org/
o "windmill" provides a sophisticated system for testing a
Python-based nosetests. Because it's much heavier and
testing and use twill for the rest of integration testing.
* Big list of Python testing library:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Portland