The SoCal Piggies had their thirteenth meeting at USC (Salvatori Computer Science Center) on April 25th 2006 at 7:00 PM. Seven Piggies attended: Daniel Arbuckle, Steve Williams, Grig Gheorghiu, Mark Kohler, Diane Trout, Titus Brown, and Greg Abbas.
Daniel was the first presenter of the night: he talked about [http://www.socal-piggies.org/presentations/daniel/2006_04_25/ Domain Specific Languages (DSLs) and Python]. WTF is a DSL was the question posed by Daniel, and of course he answered it by showing three different ways that people usually have in mind when they talk about DSLs:
domain descriptions, describing a given problem domain; some examples are OpenGL and, surprisingly, Distutils
specialized semantics, changing the usual meaning of the mother-language constructs; examples are most of the Web frameworks out there, such as Quixote, and any code that uses metaprogramming -- here Daniel mentioned the amazingly powerful [http://docs.python.org/lib/module-inspect.html inspect] module
specialized syntax, adding new constructs which can be used to describe and act upon a given problem domain; examples are twill, doctest, and the Turing-complete Postscript language; Daniel singled out the [http://christophe.delord.free.fr/en/tpg/ Toy Parser Generator (TPG)] as an exceedingly useful module which can help you create specialized syntaxes
Grig was next: he showed some examples of how to write unit tests using [http://www.mockobjects.com/FrontPage.html mock objects]. There are multiple reasons for using mock objects in unit tests:
- by mocking external interfaces (databases, network services, etc.), unit tests become fast, and thus developers are more likely to run them before every check-in
- by using canned data returned by methods called on the mock objects, we eliminate randomness and we ensure repeatability
- by simulating errors and exceptions in the methods called on the mock objects, we can test the error and exception handling code in our application, which is code that is rarely unit tested
People use the terms mock objects and stubs interchangeably. One way to distinguish them is by the fact that stubs usually return canned data, whereas mock objects keep an internal state of what methods have been called on them, and with what parameters. This makes it possible to set so-called expectations on a mock object, which tell it to expect to be called with a certain method and with certain parameters (for more potentially confusing theory about mocks vs. stubs, see also Martin Fowler's [http://www.martinfowler.com/articles/mocksArentStubs.html "Mocks Aren't Stubs"] article, which differentiates between state-based testing using stubs, and interaction-based testing using mocks.)
One useful quote from the [http://www.jmock.org/yoga.html JMock Yoga article] is the following: "stub queries and expect commands". In translation, use canned data for methods that return data to your application, and set expectations on methods that act upon an external resource using data supplied by your application. In Grig's examples, he used canned data for a database select method, and he set expectations on database insert and update methods. He promises to show a better version of his examples in a future blog post 
Grig's code used the [http://python-mock.sourceforge.net/ python-mock module] which can be downloaded from [http://sourceforge.net/project/showfiles.php?group_id=138804 here].
The next presenter was Titus, who handed out two freshly-written articles/howtos: one on [http://ivory.idyll.org/articles/wsgi-intro/what-is-wsgi.html "An introduction to WSGI"] and the other on [http://ivory.idyll.org/articles/wsgi-intro/testing-wsgi-apps-with-twill.html "Testing WSGI apps with twill"].
Titus summarized WSGI in a few words -- Think "CGI" but programmatic rather than I/O based -- and proceeded to show examples of code that needs to run on the Web server side and on the Web app side so that they can talk WSGI. All it took was a few lines of code, which was pretty impressive. Here's another quote from Titus, on why he likes WSGI: The WSGI spec is simple enough that if you can't factor your Web app interface out into a WSGI-compliant interface, you didn't write your Web app properly. This exposes lousy design for what it is.
Titus then showed his wsgi_intercept handler for twill, which allows you to test Web applications in-process, without going through the hassle of setting up a Web server on a given port, and without any inter-process communication. Pretty nifty stuff, which opens the doors to all kinds of interesting possibilities related to testing: simplified functional testing of your Web app, easy integration with code coverage and profiler tools, easy integration with the pdb debugger, etc. The [http://ivory.idyll.org/articles/wsgi-intro/twill-wsgi-doctest.py twill-and-doctest example] was also cool, and Grig did accept Titus's challenge and [http://www.agilistas.org/twill_doctest/twill-wsgi-doctest.py made it work], at least with Python 2.4.
Many thanks to Daniel, Grig and Titus for presenting, and to Daniel for providing the room at USC.
Proposed agenda for the next meeting: we need volunteers!