Introduction

I recently pushed the v.0.1.2 release of my new Django application, django- cloud-browser, to PyPi. Cloud Browser is a simple web-based file browser for cloud-based datastores, which so far includes Amazon S3, Rackspace Cloud Files (including OpenStack) and local file system. The application can expose read-only cloud files to users and/or administrators with configurations for both normal and administrative deployments.

The basic reference points to get started include:

• Cloud Browser API / documentation
• GitHub page
• PyPi page

Background

At work, we have some containers with very large numbers of objects – over 5 million and counting. While objects ultimately are named in a flat namespace, we divide up the namespace with slashes (e.g., “path/to/cloud/object/file.txt”). Nearly all cloud providers (Amazon S3, Microsoft Azure, and Rackspace) include functionality in their object APIs to return results grouped around hierarchical “implied” or “pseudo-“ directory objects based on a separator (like the slash that we use).

Despite the fact that Rackspace’s underlying REST and Python APIs both support implying directories from a delimiter like a slash, Rackspace’s own management console will only display objects using a completely flat namespace. As an example, I have an old side project where I stored US patent data in XML form in both Rackspace Cloud Files and Amazon S3, and broke up each object with a slash-delimited path. (I have obscured my bucket / container names in all of the screen shots in this post). Let’s view the objects in the Rackspace container using their web interface:

Introduction

This is the second of two posts looking at browserless AJAX / JavaScript testing with Rhino and Envjs. Last time, we set up Rhino and Envjs to run a basic set of QUnit tests from the command line, exercising pure JavaScript code with no AJAX or DOM manipulation. Today, we will add tests for code that hacks on the DOM and makes AJAX calls.

Let’s start with the files we had last time (with links to previous blog post):

• env.rhino.1.2.js: Envjs for Rhino.
• qunit.css: QUnit styles. (Link to known working version).
• qunit.js: QUnit code. (Link to known working version).
• setup.js: Our custom hook Envjs to QUnit.
• run-tests.js: Include our setup script and actually invoke the tests at on our test HTML page.
• my-lib.js: An example JavaScript library (that we want to test).
• my-tests.js: An example custom QUnit tests for my-lib.js.
• test.html: Basic QUnit HTML page (see QUnit documentation) with script links to “my-lib.js” and “my-tests.js”.

New Files and Tests

Let’s add some new libraries and tests to our working set, to include DOM actions and AJAX:

Updates - 5/27/2011

Since this original post, there has been a lot of good feedback surrounding getting an Envjs + QUnit + Rhino setup going, so please read the comments at the bottom of this post. Here are the summarized points:

• QUnit: Newer versions of QUnit have issues with Envjs, adding a <pre/> to output that Envjs can’t handle. A comment from “Ryan” (not me – I’m “Ryan Roemer” below) also points out the QUnit has changed the function signature of the logging callbacks and links to an improved “setup.js” file. I have inserted links to a known working version of QUnit.
• jQuery 1.5: jQuery 1.5+ also has issues with Envjs due to calls to a couple of methods not currently available in either Envjs 1.2 or 1.3. There is a patch on GitHub for the issue for Envjs 1.3. I have backported the patch (and some other fixes) to a forked version of Envjs 1.2 on my GitHub account.
• Envjs 1.3: Envjs 1.2 was a single file, with primarily Rhino support. Envjs 1.3 is massive enhancement project that supports a large number of JavaScript engines including: Node.js, SpiderMonkey, etc. It’s still in early development, but definitely worth taking a look at.

Introduction

This is the first of two blog posts focusing on browserless testing of AJAX / JavaScript using Rhino and Envjs. Today, we discuss getting browserless QUnit tests up and running from the command line. A follow-on post will discuss running QUnit tests which involve DOM manipulation and AJAX interaction.

Testing web applications can be an enormous pain. Tests take time to write correctly and usefully, the interaction between the front and back ends is complicated, and it is often a hassle just to get people to run the tests on a regular basis. At work as of late, we have been trying to kick start our JavaScript unit testing – our system has a Django/Python backend, and a JavaScript (mostly jQuery-based) frontend.

On the backend, we are in good shape, test-wise – the Django test case extensions to the Python unit test framework make backend unit testing easy and straightforward. Everything runs fairly quickly, and from the command line. In fact, we have actually made a (soft) requirement that all developers run a Fabric target called “precommit” that runs all of our Django unit tests (in addition to Python and JavaScript style checkers).

On the frontend, it’s a different story. Our previous test suite relied entirely on a browser and a running development server loaded with data in a known state. Our unit tests were written against QUnit, and for the most part worked fine for the code they did exercise. But, even where our frontend tests would catch newly introduced bugs, all too often the tests just weren’t run, and we would actually discover the bug several commit cycles later.

While we clearly need to integrate a fully automated infrastructure around browser-based tests (using great tools like Selenium or Windmill), my thoughts turned to the idea that the heavyweight nature of full end-to-end AJAX testing was getting in the way of us writing and running frontend tests. More specifically, the difficulties come down to two fundamental problems – our tests on the frontend are: (1) not easy to write and run, and (2) are not integrated into an automated, “one-touch” running scheme.