Category Archives: oss

Robot Framework and Sphinx: A suitable toolset for your specification by example

At work, we have been using Robot Framework for all kinds of tests for a few years now and it’s proven to be the good choice. Robot Framework’s simple syntax and grammar does not scare testers away (usually). At the same time, its design makes it easy to support complex use cases as well as simple ones through the power of the Python programming language.

One blind spot however, in my opinion anyway, is the way Robot Framework let you document your tests. It provides a section for this, with basic HTML support but it has always felt limited and not really friendly.

Luckily, in the recent releases, the Robot Framework developers have provided a built-in support for reStructuredText. Not that the documentation section supports this syntax, but instead, you can embed Robot Framework tests into a reStructuredText document, and therefore into Sphinx as well.

The gain isn’t so much visible in the Robot Framework reports since the reStructuredText sections won’t appear in those, but it means you can generate HTML documents which embed executable tests. Fans of doctests will be in known territory.

I think this is a powerful combination as it bridges the tests with the specifications and ensure they are both kept locally at the same place, imrpoving their chance to stay synchronised.  In my mind, it provides a great framework to follow the Specification by Example that Gojko Adzic described so eloquently.

Here is a simple:

Finally, a related powerful extension provides a simple mechanism to include Robot Framework tests into Sphinx documentation. We use it extensively at work as we wanted to keep our tests outside in distinct files without losing the ability to see them embedded into the generated HTML documentation.

CherryPy documentation new start

Early on this year, a discussion emerged on the CherryPy mailing-list about the project. Most people said they loved the project but had struggled with its documentation. Though rich and extensive, it was felt it left down the project somehow by being not designed in a way that was attractive to new comers. I took upon myself to rewrite it from scratch following some ideas exchanged on the mailing-list.

The general expressed wish was to make it friendliers to people starting with the framework whilst making easy to look for common tasks and patterns. This suited me well as I wanted to carry the work I started on the various recipes I keep on BitBucket.

Eventually, I quickly wrote a set of tutorials to guide people through the general layout of a CherryPy application. Then I developed upon the recipes idea by going through many of the most recurrent questions we have on the mailing-list. Finally, I wrote an extensive section regarding the core features of the framework: plugins, tools, the bus, the dispatchers, etc. Those features are seldom used to their best even though they provide a very powerful backbone to design your application in clean way.

The documentation is now online and seems to have been well-received. It will need to be completed but I believe they already make the project much more appealing and fun to work with.

XMPP and IronPython 2 using headstock, bridge and Kamaelia

I am glad to announce that IronPython 2 is now capable of running my XMPP
Python library: headstock.

.NET has already an excellent XMPP SDK called agsXMPP that is a native
.NET/C# framework. However I’m a Python developers at heart and I had
started quite a while ago writing my own XMPP library in Python using the
most excellent Kamaelia framework (designed for concurrency).

For a while IronPython had severe shortcomings that prevented it running
simple Kamaelia applications. Today I was able to run a simplechat demo
using a vanilla IP2 on Windows with only one single modification to the
logging module (thanks Seo). To be honest I didn’t expect it to go through
:)

The chat demo is simple enough but means more complex examples using XMPP
PubSub will work as well (they are all based on the same framework).

Now this isn’t production ready or anything. For instance the TLS support
is broken (hopefully something easy enough to fix) so you won’t be able to
connect to Google Talk for now.

Moreover I’m not sure the code is that fast considering how I had to
simulate an incremental XML parser atop System.Xml (this allows for a
XML stream to be parsed without requiring the full document or even
fragment to be read first).

This is a great news for me because it means I’ll be able to move ahead
with more work using IronPython 2.

They made me do it…

I had to.
More seriously though since the work I’m doing with XMPP and AtomPub these days, I thought it be a nice idea to try and plug into Twitter somehow. I guess I won’t be using Twitter much for anything else than testing. We’ll see.