[portland] Meeting notes: August 11, 2009 - optparse, and testing in a Python world

[Igal Koshevoy]

We had our first meeting at the new venue.

THANKS

    * WebTrends for providing the meeting space: http://www.webtrends.com/
    * Emma for providing pizza: http://www.myemma.com/
    * Volunteers for bringing beer


PRESENTATIONS

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
            library. Documentation:
            http://docs.python.org/library/unittest.html
          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:
            http://codespeak.net/py/dist/test/test.html
          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:
            http://docs.python.org/library/doctest.html
          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
            transaction. Documentation:
            http://docs.python.org/library/doctest.html
    * 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"
            method replaced.
    * 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:
            stop server.
          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
            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: http://www.getwindmill.com/
    * Big list of Python testing library:
      http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy


-igal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/portland/attachments/20090811/d991d900/attachment.htm>