Testing a dynamic language

A colleague recently complained to me that I'm forcing him to write a unittest without a good reason. He had written a small method which he told me that there's almost no way of breaking, it's so trivial that it doesn't need a test.

The code in question was written in Python and looked like this:

from some.module import Settings

 
 
 class Object(Base):
  def is_fluff(self):
    return self.state == Settings.STATE_FLUFF

In his change he added the is_fluff method, which wasn't previously defined (but self.state) was.

I told him that there are a actually possible to break the method in a number of different ways:

1. by changing the method name
2. by changing the attribute name
3. by changing the constant name
4. by changing the constants module name
5. by changing the type of the attribute
6. by changing the type of the constant
7. by changing the value of the constant
8. by changing the operator
9. by changing the function prototype
10. by removing the return keyword
11. by subclassing the object and overriding the method

This is not a complete list since Python is a very dynamic language. You can change the behavior of objects in various interesting ways. Overriding attribute lookup, the comparision operator, class creation, method invocation etc etc etc

So by writing a very simple test like this:

o = Object()
o.state = Settings.STATE_KLARKE
assert not o.is_fluff()
o.state = Settings.STATE_FLUFF
assert o.is_fluff()

The moral of the story is that we're actually testing a lot more than just a simple comparision in a dynamic language like Python where the compilation process is very simple.

This is not an attack on dynamic languages like Python. A language which does extensive type checking at compilation time is likely to catch a few of the possible errors I listed, but not all of them. The most dangerous one is changing the value of the constant, no tool in the world can help you catch that. (assuming our object is going to live longer than the time of our program, eg the values are going to be saved in a database)

You'll need to write a unittest for your program regardless of the language you choosed to implement it in. Python makes it easy to write and maintain code and since unittests should be written anyway it's on the winning side ;-)

Pyflakes and Subversion

Pyflakes is a nice little utility that checks your Python code for errors. The main advantage over PyChecker and PyLint is that it is much faster and gives almost no false positives. Today I wrote a little hack on top of the enforcer pre-commit script which forces the code you check in to pass pyflakes. Eg, the users of svn will see the following output if they try to check in code which has errors pyflakes can detect:

$ svn ci -m "fix" completion.py
Sending        completion.py
Transmitting file data .svn: Commit failed (details follow):
svn: 'pre-commit' hook failed with error output:
Pyflakes found 1 error(s)/warning(s):
kiwi/trunk/examples/completion.py:1: undefined name 'test'

The small "configuration" file for enforce can be found here.

Planet filtering

Today I decided to figure out how to filter out certain blogs from Planet GNOME. It turned out to be much easier than I thought. Just create a csimple rule using css selectors and add it to our chrome-UserContent.css file.

So if you're tired of listening to the complaints of the scandinavian cabal, add this to your customized css file:

@-moz-document domain(planet.gnome.org) {
  div.richard,
  div.hallski,
  div.uraeus { display: none; }
}

Mozilla/Firefox only, perhaps only 1.5 or newer, who cares.

Gedit plugins

Richards little devhelp plugin for Gedit made me motivated enough to start looking at the plugin framework.

As he points out, the interface nice: simple and straight-forward. I decided to give it a go and wrote a little plugin to do remote editing, a la gobby. It allows you to share a buffer and connect to a remote one. It's little more than a proof of concept, but it allows you to edit the same document from different instances of gedit. All done in about 200 lines of python, including a custom protocol for remote editing. Twisted made that experience almost trival.
If anyone is curious and want to try it out fetch the tarball from here.

PyGTK

Today I finally branched for Gtk+ 2.10. There are quite a few bugs with simple patches attached to in bugzilla. Gustavo suggested that we should do a bug day, which would be great. Especially if we can get a couple of new contributors.

Yesterday I got inspired by the performance work federico posted. I decided to take a look on why gnome_vfs_get_volume_monitor() was so slow. After some investigation, a few modifications (adding colors and crude execve support) to the nice pycairo script federico wrote to plot strace logs and adding some markers to bonobo-activation, I came up with the following plot:

The python script I used to test can be found here.

Just before running this I did the tail /dev/zero trick (with swap turned off) to "flush" the kernel cache.

As the graph quite clearly states, bonobo-activation-server is spending about one second listing directories, reading and parsing .server (xml) files. The gconfd-2 startup is probably not so bad (it used to be a lot worse), but I do wonder why it takes so long time to import gnomevfs.

When can we have DTrace for Linux?