steal our code

I was ruminating on Flumotion, the free-software streaming server that I hack as a day job. We don't really do contributors. That's not because of a lack of public SVN, not because of a lack of a public bugtracking system. We're not assholes either. So what gives?

Well, for whatever reason, Flumotion doesn't have developers outside of Fluendo, the company I work for. But those of us that do hack it are a prideful bunch. Thomas writes frequently about it, Mike takes every critical bug as his own, and Zaheer spends weekends expanding its feature set. So we have code we care about, code that is free software, but code that nobody sees, as far as I can tell. This is in spite of our trac's absurdly high google juice.

So if hackers won't come to Flumotion, Flumotion should come to hackers. Take our code! It's all licensed under the GPL, so you can probably use it in your free software project. Of course, using python helps, but is not always necessary; using Twisted helps even more. But some things can be used by any project, for example today's example.

integration test suite code

An integration test is like a unit test, but larger. It merits a different name because it involves multiple processes. Flumotion has code to write integration tests as normal trial unit tests.

flumotion.twisted.integration is here: the code (steal this!), its unit tests, and an example usage.

Concretely, an example usage might be this:

from twisted.trial import unittest
from flumotion.twisted import integration
class TestEcho(unittest.TestCase):
    @integration.test
    def testHelloWorld(self, plan):
        p = plan.spawn('echo', 'Hello World')
        plan.wait(p, 0)

This test is marked as an integration test by its decorator, integration.test. The test gets an extra argument, plan, which it is expected to populate. In this case the plan has two steps: one to spawn the echo process, and one to wait for its successful termination.

In the event that something unexpected happens, the test will fail. Precisely, "something unexpected" is an unexpected process exit (an exit without a wait step in the plan), processes hanging around when the plan has finished, or an exit with an unexpected error code or signal. Furthermore there is a default timeout, which can be adjusted for specific tests. In the event of a failure, stdout and stderr of all spawned processes will be left on disk in separate files for the developer to analyze.

The only other operation available on plans, besides spawn and wait, is kill, to kill a process with some signal. Pretty simple, but powerful enough to test large systems. We use it to test our streaming platform software, in which each test spawns dozens of processes.

And with that, we wrap up this first of N articles on Flumotion internals that people should use. Happy hacking!