<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
We had our first meeting at the new venue.<br>
<br>
THANKS<br>
<ul>
<li>WebTrends for providing the meeting space:
<a class="moz-txt-link-freetext" href="http://www.webtrends.com/">http://www.webtrends.com/</a></li>
<li>Emma for providing pizza: <a class="moz-txt-link-freetext" href="http://www.myemma.com/">http://www.myemma.com/</a></li>
<li>Volunteers for bringing beer</li>
</ul>
<br>
PRESENTATIONS<br>
<br>
1. Michelle Rowley presented optparse, the module of the month<br>
<ul>
<li>"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.</li>
<li>Reference and tutorial:
<a class="moz-txt-link-freetext" href="http://docs.python.org/library/optparse.html">http://docs.python.org/library/optparse.html</a></li>
</ul>
<br>
2. Adam Lowry presented "Testing My Patience", discussing testing in
Python<br>
<ul>
<li>Unit Testing helps ensure the correctness of a small piece of
code, like a method or class.<br>
</li>
<ul>
<li>"unittest" is a simple way to write tests as a series of
methods in a single file. It is part of the Python standard library.
Documentation: <a class="moz-txt-link-freetext" href="http://docs.python.org/library/unittest.html">http://docs.python.org/library/unittest.html</a></li>
</ul>
<ul>
<li>"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:
<a class="moz-txt-link-freetext" href="http://codespeak.net/py/dist/test/test.html">http://codespeak.net/py/dist/test/test.html</a></li>
<li>"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:
<a class="moz-txt-link-freetext" href="http://docs.python.org/library/doctest.html">http://docs.python.org/library/doctest.html</a></li>
<li>"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 transaction.
Documentation: <a class="moz-txt-link-freetext" href="http://docs.python.org/library/doctest.html">http://docs.python.org/library/doctest.html</a></li>
</ul>
<li>Terms for faking it</li>
<ul>
<li>"Mocks" are fake objects used for testing. E.g., an object
pretending to be a User class.<br>
</li>
<li>"Stubs" are real objects with parts replaced for convenience of
testing. E.g., a normal User class with the "first_name" method
replaced.<br>
</li>
</ul>
<li>Mocking and stubbing tools</li>
<ul>
<li>"Mock" by Michael Foord provides decorators for test methods
that temporarily replace specified methods elsewhere in your code.
Documentation: <a class="moz-txt-link-freetext" href="http://www.voidspace.org.uk/python/mock/">http://www.voidspace.org.uk/python/mock/</a></li>
<li>"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.</li>
</ul>
<li>Integration and functional testing</li>
<ul>
<li>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.</li>
<li>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: stop server.</li>
<li>If you're using a framework (e.g., Django, TurboGears, etc),
you should try to use it's testing system to make this easier.</li>
<li>"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: <a class="moz-txt-link-freetext" href="http://twill.idyll.org/">http://twill.idyll.org/</a></li>
<li>"windmill" provides a sophisticated system for testing a
JavaScript in a web application. You can run it from your Python-based
nosetests. Because it's much heavier and slower, it's often best to use
it just for JavaScript testing and use twill for the rest of
integration testing. Documentation: <a class="moz-txt-link-freetext" href="http://www.getwindmill.com/">http://www.getwindmill.com/</a></li>
</ul>
<li>Big list of Python testing library:
<a class="moz-txt-link-freetext" href="http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy">http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy</a></li>
</ul>
<br>
-igal<br>
</body>
</html>