blog: Unittesting Life

(Just in time for New Years! This is good for resolutions...)

So I'm half writing this to pitch LifeUnit, the Django application that I just wrote. And I really mean that: I just wrote it, as in, today. The Mercurial repo tells me it was about three hours from the initial Django app to when most functionality was there.

I'm also half here to describe how some of the development went.

LifeUnit is something I've been thinking about for some time. The idea comes from Michal Wallace; I actually first ran across it when I was looking at Scarlet Lambda, although SL never did take off. (Shame...)

I wrote an implementation in mot, the same framework that I wrote for this site, but honestly I'm a little sick of dealing with my own code. It was a single-user, proof-of-concept application, and I used it for maybe a week. However, I put in the usual unit test features of having multiple suites, and tried to do this fancy thing where a test could belong to multiple suites and each suite could be evaluated individually and... it was confusing to use, let alone debug.

So today I decided to write a simpler, multi-user implementation in Django. And to my surprise, it's now up. The toughest part was finally buckling down and learning how to do Apache virtual hosts.

The Cool Stuff

The basics are pretty simple. You sign up and create any number of tests for yourself. Each day, you log in and "run" your tests, which really means going down the list and clicking "PASS" or "FAIL". (When you click it, it turns green or red, respectively. Cool, no?) Then, when you refresh the page, it'll tell you what percentage of tests you've passed for that day. You can also view your history of tests at any point in the past (or future, if you feel like getting a head start on those).

Once I get a few days' worth of data in there, I'm going to add charts... I haven't decided whether they'll be Google Charts-based or Flot-based.

Anyway, that's the entirety of the workflow right now. Obviously, some sort of API would be useful, but right now I'm only using it through a browser.

I Code Badly and With Great Haste

Although I had my previous implementations to work from, I have to admit that I was kind of impressed with myself for getting it up so quickly.¹ In many ways, my enthusiasm is my most scarce resource, so I cut all kinds of corners to get it done today, while I'm still interested in it.

Model-wise, it's dead simple: besides the built-in user models, I have two models, one for tests and one for results, and that's it. The entire models file is 11 SLOC.

So there aren't actually any ugly things in the models. In the views, however... yeah, there are. Although I'm using the built-in Django users, and even the login_required decorator, I cheated: I just have the login_required URL point to my login form, as I didn't feel like grokking those docs. Likewise, I use hand-coded forms, not newforms, although I borrowed a few conventions from newforms (like centralizing the label/field combinations and leaving the form and submit tags to each individual page template).

The login function itself is quite ugly, as it handles authentication, account creation and validation all in one. Ugh. But I only had to write one of them.

The last ugly thing in the views is the use of locals() as the context for every template render. I'm lazy, and I always want the request object passed as context anyway, so... why not?

Oh, and the entire thing is undocumented and pretty hard to read. Geez.

I don't have the Mercurial repo available publicly yet, because I never got around to setting up my Mercurial webdir, but I promise I will soon.

Anyway, if you're into the whole "judging testing yourself" thing, check it out, and ping me with any suggestions.