Daniel Nouri's Old Blog

The Document Library document management system has seen lots of improvements lately. There'll be a new release shortly. We've been busy adding:

• easy installation, using Zope Buildout,
• LDAP support, based on ldappas and ldapadapter,
• filesystem storage support, based on Tramline and hurry.file and
• a more reliable conversion between file formats, provided by the OooConv conversion server, which now has an easy way to install it, too.

Quite a number of different components are involved. And that's only the list of recently added dependencies. Code reuse is good. The working together of these components, however, needs extra care, because components will change over time and we need a way to make sure that the Document Library doesn't break, or that its breakage is apparent when we update its dependencies to newer versions. Testing the Document Library's APIs in isolation isn't enough here. Neither is leaving the testing to the user.

The optional filesystem storage support requires Apache in front of Zope. The conversion mechanism requires a running OooConv process (which in turn controls a number of Open Office worker processes). And then we allow mass uploading of documents using ZIP files, the contents of which may want filesystem storage and conversion, too. This leaves us with quite a number of variables, and lots of ways to screw up.

Manual testing of all of these combinations is tedious. Let's say a human tester prepares a testing session by writing down all the possible combinations he can think of (which is what we did, too). He tests document adding, editing, validation errors and uploading with Tramline and without and conversion with Tramline and without and with ZIP files.

Lots of functionality is cool, but it's also worrying. Will feature A combined with B under circumstance C still work when I change this line of code? Doing all the human testing after we do a change isn't an option. But not doing it feels bad.

The answer to this is to write automated functional tests. For that, we decided to use the Zope Testbrowser (with doctest), which has already proven itself a very useful tool in the past.

Now you might already know that Testbrowser has a mode for testing against any HTTP server. In our case, this mode is the only way to test conversion and filesystem storage, because both of these features require help from external processes.

Before running these Testbrowser tests now, the tester start up Apache and the conversion server and points Testbrowser to Apache. The tests work very similarly to human testing: A Document Library is created through the web browser, documents are added, edited, files are uploaded, mistakes are made to trigger validation error etc. And all that in a well-defined manner which leaves little place for human testers to make errors or forget about a certain test. (They can still forget to run the tests, though. ;)

At this point, I stopped worrying about breakage. And I learned that these functional tests are the bomb.

One thing worth noticing is that in these remote functional tests, we can't use the Zope Testrunner's -D option. This would normally put us (= the debugger) right at the relevant point of the application code where the test failure occurs. However, we can still run Zope in foreground and put breakpoints into the application code, or into the test code. Which means that at any time into the tests we can introspect the state of the application by either looking at variables in the debugger, or by simply browsing the Document Library instance that's being tested in Firefox.

If you want to read more about automated tests, check out this big list of interesting articles and links from Grig Gheorghiu.

Big thanks to Daniel T. Chen a.k.a crimsun on #alsa (freenode) who helped me get audio capture (recording) working on the Sony Vaio VGN-FE31M on Ubuntu Edgy.

Edgy comes with ALSA 1.0.12. What you need to do is get ALSA 1.0.13 driver sources and compile them:

$ wget ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.13.tar.bz2
$ tar xjvf alsa-driver-1.0.13.tar.bz2
$ cd alsa-driver-1.0.13
$ ./configure --with-cards=hda-intel,usb-audio --with-oss=yes \
  --with-sequencer=yes --with-kernel=/lib/modules/`uname -r`/build \
  --with-debug=full
$ make && sudo make install-modules && sudo depmod -e

Now reboot and have sound recording working!

For turning on and off the internal mic you must run alsamixer, then in the catpure view select Line and hit space. The letters CAPTUR should appear in red above the word Line. If you want to activate the internal microphone, select Mic and hit the space bar. (Thanks to gnubien for explaining this!)

A feature that I missed in Metacity (the default Window Manager of GNOME nowadays) since my old FVWM days is focus follows mouse. This is easily configured in Metacity as I found out today:

gconf-editor /apps/metacity/general/focus_mode

Set this to sloppy and your windows are focused whenever your mouse enters them.

While you're at it, you might want to also check auto_raise and set auto_raise_delay to 0, so that the focused windows raise to the front.

Update: Jasper just tells me that you can configure the same by going to System -> Preferences -> Windows in the Gnome menu.

Our prachtig cat, Sultan.