What follows is essentially a stream-of-consciousness dump from the PyAtl meeting tonight.
Python Atlanta Meetup 2009-05-14
Miscellaneous
They're recruiting people to do A/V work during PyCon here in Atlanta next year. Does this mean I get in to the con for free?
Hot Topics
- Community - you can get a lot of benefit from small-scale con-style stuff; look for the upcoming article about PyOhio in Python Magazine
- Distutils - Interesting things on the distutils mailing list
- IronPython - lots of buzz, but it's not relevant to me right now
Testing with Nose
Alfredo Deza presenting.
Talking about testing Supay (a daemon module; named after an Incan demon god). Why another daemon module?
- PEP 3143
- It's really a service, not just a daemon
- At least it's not a new web framework
- Start, Stop, Status
- Spawn children
Originally testing was done in Pythoscope. Easy to get started. Moved on to nose. Had problems because things under test were backgrounding, etc. People on the testing in Python mailing list advised him to test smaller chunks. coverage does testing coverage reporting for nose. coverage gives you really specific (package-specific, etc.) statistics.
The cool thing about nose is that it autodetects your tests.
One early gotcha: You have to invoke nose using nosetests. ed. I might as well alias `nosetests` to `nosetests -v --cover-package=$package_name`. Simply add --with-coverage to get the coverage report.
Cool, Pythoscope generates test stubs for you. I need me some of this.
Intermission
There was some A/V stuff going on here, so they took this opportunity to hand out books for review. I scored Expert Python Programming.
Choosing a Testing Framework
Brandon Rhodes presenting.
Intro
At first, he thought testing would help most by helping to get it right at first. Once he started testing, he discovered that it helped most with finding regressions. Much like undo, now he can't imagine getting by without it. One thing to note: installed Python packages rarely ship with tests, so if you want to muck around in them, you typically need to download the tarball yourself.
What does Python testing look like without a framework?
Uses setuptools, so you can just use the built-in test command. You can use an additional_tests function to build a test suite for setuptools. setuptools will not autodetect doctest tests. All in all, this is a pretty well-behaved module.
Sidenote: virtualenv - creates local, tiny Python install that you can use to avoid system-wide changes. I've seen it mentioned before, but this is the first time I've seen it in action; this could be seriously cool.
Has a README.unittests (referenced from README) that tells you exactly how to do things. There is a lot of work to manually keep track of the tests in modules; obviously, this is begging for someone to forget to add a test to the suite.
The tests here are pretty idiosyncratic (each test defines a complete web app and puts it through its paces). It uses part of zc.testrunner.
Three testing frameworks
Python testing frameworks:
- zc.testrunner
- py.test
- nose
Questions you should ask:
- How are tests discovered?
- How can tests be filtered and selected?
- How fancy are tests when reported?
One benefit of testing frameworks is that it makes the testing in your project look like the testing in other projects that use the same testing framework.
zc.testrunner
Not really covered beyond what we saw with Grok.
py.test
Finds tests based on a naming convention; this is not configurable. Tests are just functions; you don't need a class w/ test methods. You can tag tests any way you want. By default only outputs print statements if it fails. Has distributed tests and multiplatform, but the documentation is a bit sparse. Uses a module to turn on autodetection for doctest tests.
nose
Finds tests based on a naming convention; this is configurable. Tests are just functions; you don't need a class w/ test methods. You can tag tests any way you want. Has more extensive documentation and seems to have momentum.
It is probably feasible to write your tests so both py.test and nose can find and run them.
Selenium Demo (lightning talk)
Brandon Rhodes presenting.
Not a lot new to me; already used Selenium at work. The Python client seems to be doing a pretty good job of being Pythonic; the tests use unittest, etc. The basic commands seem pretty similar to the Java client I've used before.
Google Code and Hg (lightning talk)
Alfredo Deza presenting.
Brief compare/contrast between hg and svn. I'm already familiar with both so I won't recap this part of the presentation.
Traditionally, svn has been the standard for Google Code. They're giving invites to anyone attending the Google IO Conference (next week?). They're also accepting applications here; this is for old projects and they will move it over to keep the history. Not all features are available on the Mercurial version yet, e.g., code browsing.
Coolest feature: hg serve. It sets up a web interface to your entire repo on localhost:8000. It's pretty sophisticated, and allows you to push and pull from it.
And that concluded the evening.
Back to flipping out…
