Brad Pitcher

How to write unit tests for Inkscape plugins

Sun, 11 Oct 2015 18:12:03 +0000

When I first put together my Inkscape OpenSCAD DXF export plugin, I never considered writing unit tests for it, assuming it would be impractical. Years later, I revisited the possibility and found it to be not only practical, but absolutely necessary. A bug was reported against the plugin that only manifested in a recently released version of Inkscape which introduced a backward incompatibility.

Now, I didn’t want to go about manually testing different types of SVG elements on both current versions of Inkscape, so I set about investigating what it would take to write unit tests.

Triggering the export

Through manually toying in the Python shell, I found that I could trigger the plugin export by instantiating the plugins effect class and calling the affect method with an array containing the path to an SVG file as an argument. My plugin stores the results in a member variable, so I could compare that against known good output. Something like this:

from openscad_dxf import OpenSCADDXFEffect

effect = OpenSCADDXFEffect()
effect.affect(['tests/files/circle.svg'])
with open('tests/files/circle.dxf', 'r') as dxf_file:
    self.assertEqual(effect.dxf, dxf_file.read().rstrip())

Testing multiple Inkscape versions

Testing multiple inkscape versions locally is a bit of a pain because I couldn’t find a way to have them both installed at once. Here’s where Travis came in handy. If you aren’t familiar with the Travis service, I highly recommend checking it out. With Travis I was able to specify a test matrix of multiple Python versions and multiple Inkscape versions and the service now runs my unit tests with all combinations of the specified Python and Inkscape versions. Here’s the configuration I started with:

language: python
python:
  - "pypy"
  - "2.7"
# Test both current major versions of Inkscape
env:
  - INKSCAPE_VERSION="0.48.3.1-1ubuntu1.1"
  - INKSCAPE_VERSION="0.91.0+37~ubuntu12.04.1"
# command to install dependencies
install:
  - sudo add-apt-repository -y ppa:inkscape.dev/stable
  - sudo apt-get update -qq
  - sudo apt-get install -qq "inkscape=$INKSCAPE_VERSION"
  - pip install -r test-requirements.txt
# command to run tests
script: nosetests --with-coverage --cover-branches
after_success: coveralls

Allow me to break down the important pieces here. First, we specify the Python versions to test against. We only list pypy, and 2.7 here because there is still some Inkscape plugin code (that my plugin depends on) that doesn’t work with Python versions greater than 3.

In the env section we specify the Inkscape versions to test against. The long version strings used here are the versions of the packages in the Inkscape.dev Ubuntu PPA.

In the install section, we add the PPA, install the package, and pip install any other Python testing packages required.

Finally, in the script section we run the tests. I like to run my tests with coverage, so I can run coveralls after the tests to get a nice looking code coverage report on the web.

With this configuration in place in my repository, all I had to do was enable the repository on travis-ci.org and push to GitHub to let Travis do it’s work.

Running Inkscape headless

In my case, I wasn’t quite finished yet. For reasons I won’t go into here, my plugin needs to spawn a full GUI instance of Inkscape to work. When running the tests locally, this is a non-issue. I just watch the windows pop in and out of existence as the tests run. However, a Travis test server is a headless environment which means it has no peripherals attached to it, including a display. When I tried to run the tests using the configuration above, they failed when trying to spawn Inkscape.

Fortunately, there is a simple way to get GUI processes to work in headless environments. There is a handy service called xvfb (X virtual framebuffer) which creates a virtual display on which to show any GUI processes. We can start the service on a Travis server with just a few extra lines of configuration:

# Start xvfb so we can run Inkscape headless
before_install:
  - "export DISPLAY=:99.0"
  - "sh -e /etc/init.d/xvfb start"

With this configuration in place, all I have to do is push my changes and Travis automatically verifies that the expected dxf files get produced in both current Inkscape versions with the new code.

I hope this walkthrough of my experiences helps you to write unit tests for your own Inkscape plugin. Please feel free to browse the code to see how I fleshed out the tests from here.

Welcome to One Wheel

Thu, 24 Apr 2014 05:07:37 +0000

UPDATE (2015-10-10): This site is no longer powered by Ghost, but instead by Jekyll. I’m keeping this page up however for historical purposes.

This site is powered by the relatively new blog platform called Ghost and running on Red Hat’s cloud platform: OpenShift. Both are open source software, so I figured—in the spirit of openness—I should share how I got these technologies working together. If you’d like to follow along, the free tier of Open Shift service gives you 3 gears, which is more than enough to run Ghost.

Why?

If you want to get straight to the how, feel free to skip ahead.

Why Ghost

Ghost aims to be a simple blogging platform and nothing more. The biggest core feature in my mind is the beautiful simplicity of the editor, which makes writing content the top priority. Using markdown with an automatically updating preview pane allows you to write without your hands ever leaving the keyboard. Use keyboard shortcuts to insert placeholders for images and links, then when finished writing you can go through and add all the real images and links. See the feature list for a full run down.

Why OpenShift

OpenShift is a completely open source platform as a service (PaaS) for hosting apps made with all the modern popular web languages/frameworks (including NodeJS of course, which is what Ghost is built on). The fact that it’s open source means you aren’t locked in. If you don’t like openshift.com, you can take your app to an alternative host, or roll your own from the OpenShift Origin Server. Definitely try openshift.com though. They have a free tier so you can try before you buy.

How?

Install `rhc`

First, you need to install and setup the OpenShift command line client. Red Hat has decent instructions for how to do it on multiple platforms so I won’t repeat that information here.

Quickstart

Thankfully for me, the hardest part is already done. The folks at Red Hat must like Ghost because they have already created an OpenShift Quickstart for Ghost. It is just one of many Quickstarts they have created for some other great open source projects, like Drupal, Plone, and Tomcat just to name a few. Now that you have rhc installed, drop into a command prompt and run the following:

$ rhc app create ghost nodejs-0.10 --scaling --env NODE_ENV=production --from-code https://github.com/openshift-quickstart/openshift-ghost-quickstart.git

Replace ghost with the name of your application. Using the --scaling option allows you scale your app up to handle the load if needed. You cannot change this later so if you want your app to be scalable you need to use this option now.

After creating the app with rhc, you should be able to see it at https://<appname>-<domain>.rhcloud.com/, replacing <appname> with your application’s name and <domain> with your OpenShift domain name. Yep, it already works! Now to customize it.

OpenShift Web Console

Login to the OpenShift web console and you should see your new app. Tap on your app to see the detail page where you can view and change various settings. On the detail page, you will see your git repository URL. Use it to clone the repository to your computer. Anytime you push a change to the master branch in that repo, OpenShift automatically deploys the changes.

Database setup

If you know you aren’t going to scale and you aren’t worrying about performance issues, you can skip this step because the quickstart comes configured with sqlite out of the box. For everyone else, you should use MySQL or PostgreSQL (at the time of this writing Ghost supports sqlite, MySQL, and PostgreSQL). Thankfully, it’s just a few simple clicks from your app detail page to add a database cartridge.

After adding a DB cartridge you should have a list of configuration options to use in Ghost. Save these options for the next step.

config.js

Open the config.js file in the root of the repository you cloned from OpenShift. This file contains all the configuration options for Ghost, but we are only concerned with the production configuration, so scroll down to the production section. If you are changing the database, replace the database section with something like the following.

database: {
    client: 'pg',
    connection: {
        host     : process.env.OPENSHIFT_POSTGRESQL_DB_HOST,
        port     : process.env.OPENSHIFT_POSTGRESQL_DB_PORT,
        user     : 'user',
        password : 'password',
        database : 'database',
        charset  : 'utf8'
    },
    debug: false
},

Replace the values for user, password and database with your own information. If you didn’t make note of it earlier, you can get it from the web console at this point. If you chose to use MySQL, you can use process.env.OPENSHIFT_MYSQL_DB_HOST for the host and process.env.OPENSHIFT_MYSQL_DB_PORT for the port.

I also highly recommend setting up the mail settings now. Without proper mail settings, your ghost installation will not be able to send email. To use Gmail, replace the mail section with something like the following:

mail: {
    transport: 'SMTP',
    options: {
        service: 'Gmail',
        auth: {
            user: 'gmailaddress',
            pass: 'password'
        }
    }
}

You can also change the url value to whatever custom domain you may be using. If you do this you will also want to add your domain as an alias in the OpenShift web console.

Now that we’re all set up, we can try signing in. Go to https://<appname>-<domain>.rhcloud.com/ghost and create a username/password. Uh oh, did you get a 503 error? Not to worry, this is a known error that is being worked on, but your user was created successfully. Just go back to https://<appname>-<domain>.rhcloud.com/ to logon and test out your new Ghost system.

Fin

Happy ghost writing! Please feel free to ask me any questions or post more solutions in the comments.