Category: pycon2007

Oh, wait; not that sort of mocking. Fine. Following the talk on using the fixture package, Jeff Younker spoke on using the PyMock package for unit testing with mock objects. Younker spent the first few minutes of his talk talking about unit testing in general; what I initially thought was simply a meandaring exposition on the nature of testing was actually going somewhere: adding tests to existing code can be painful, because of how intertwined things can be. Creating mock objects can help you isolate pieces of the code from the remainder of the application.

PyMock makes this somewhat simpler by providing a way of “recording” what you want your mock objects to return, and the going into “play back” mode to run the test. It provides a way to mock methods, attributes and generators on Python objects.

Things I’m sure of following the talk:

• The idea of mocking objects seems like a powerful way to isolate pieces of existing code for the purpose of testing.
• Showing a slide full of code, with near-zero explanation, for only a few seconds before moving on, isn’t long enough for me to grok it; judging by the under-the-breath comments from those around me, I’m not alone in this.
• Unit tests are hideously ugly when compared to the beauty of doctests.

Following Jim’s talk on zc.ngi, I attended Kumar McMillan talk on using Fixtures to test your programs. According to McMillan, fixtures differ from mock objects in one important way: they use real objects with real data. I haven’t used fixtures or mock objects much, so that was a useful distinction.

McMillan is the developer of the fixture package, which provides a way of loading and referencing test data for your application. fixture also allows you to write tests against fixture objects using either a mixin or a decorator[1]_. Fixture supports loading data into SQLAlchemy and SQLObject; CSV and possible Django support are also under consideration.

Fixture is a relatively young project, but it does appear to be useful for testing data-driven applications.

Following the keynote this morning, I attended Jim Fulton’s talk on testing network applications with the Network Gateway Interface. Jim advocates the use of doctests, in particular doctests which allow you to mix the documentation and narrative together (note to self: write a post about why this is compelling). When programming network applications, writing tests can be really, really hard: there can be sockets, time.sleep(), threads, etc.

In response to running into these problems with testing ZEO, Jim developed a library called the Network Gateway Interface (NGI). The goal of NGI is that application code doesn’t touch socket code. NGI splits the network application into two pieces: the application side and the implementation side. The application side doesn’t need to be thread aware (or even safe) and uses events to communicate with the implementation side. And the implementation side handles the actual socket or transport work.

Jim’s talk used the example of a simple application, z2monitoring, to demonstrate the NGI. The goal of z2monitoring was to monitor and get status from a running Zope 2 application at the time when status is needed most: when the application is bogged down, responding to requests. When testing with NGI, you create a special testing connection, such as a TextConnection (which just uses plain text). The connection conforms to the IConnection interface, which also provides a way to set the connection handler. The connection handler (IConnectionHandler, natch), is used to respond to events like input, connection close and exceptions.

In addition to the async, event-driven interface, zc.ngi provides a simple, blocking file-like API. This is convenient for developing simple, single-task applications.

Jim spent a short part of his talk discussing about the benefits of non-determinism, such as the existing ZEO implementation. One of these was the “opportunity for the unexpected.” Of course, Jim also noted (with an unclear amount of irony) that production is also a form of testing.

NGI 1.0 was released just before PyCon, and this will probably be the last release. [Un]fortunately, Jim recently found that Twisted provides facilities for this style of programming and testing. Given this, zc.ngi will probably only live on (if at all) as a simplified facade over Twisted’s facilities.

Matt summarizes the PyCon’s Testing Tools Panel far better than I could here. I was also hoping for some more… depth, perhaps? I think that a problem with both the web frameworks and testing tools panels is that they had too many participants for the half-hour-ish time slot. Regardless it served as a good overview of the available tools (if nothing else giving me a list to start Googling from).