Backfilling spec coverage and refactoring: technical debt edition

Hello friends,

So what happens when a project comes to life by inspiration and accident, then gets picked up and starts getting used in the field? Well, it's a balancing act of adding new features and tending the codebase garden so that future features are possible.

Let's call this PR a bobcat re-landscaping effort.

![bobcat](https://cloud.githubusercontent.com/assets/261548/2871103/dec95020-d2f2-11e3-846b-6d3a3cb8746d.jpg)

The goal here is backfill missing unit test coverage in critical parts of the codebase for 3 big reasons:

1. Make future [refactoring](http://c2.com/cgi/wiki?WhatIsRefactoring) quicker and lower stress. It becomes extremely expensive to properly refactor without a safety net of tests--they help enforce the previous contract for any new or modified production code.
2. Allow more safety when accepting pull requests and contributions. Once a more complete code coverage is achieved, we will start to ask for accompanying unit and/or integration tests to accompany pull requests. This benefits everyone :heart: 
3. Provide more use cases and developer documentation when navigating the codebase. Developer docs and code examples are one dimension of a successful "documented project".

If adding spec coverage to a "legacy codebase" interests you, then please follow along. If this sounds scary and tedious (and it can be), then please a glass of something tasty when this PR is finally ready for a merge.