For the past six months I've been actively working to make listparser the single best subscription list parser available, and I've had a blast working toward that goal. I've spent most of my time improving the library, but my unit test code has begun to resemble a shanty town; the number of unit tests has grown, certainly, but they've obviously been dumped off in lptest.py.

Today I've been spending a good deal of time turning that shanty town into a respectable village, using a bunch of function factories to spit out prefab TestCase functions. In doing so, I've reduced the amount of time it takes to run the unit tests, and I've even caught another crasher bug! (I consider any uncaught exception to be a crasher bug.)

So why put in the effort to improve the unit tests? (And here I'll drop the shanty town metaphor, lest I say something about how the unit tests do the same job regardless of whether they're comfortably organized or not.) The reason is simple: lptest.py serves as a basis for writing unit tests for anything else I work on. Remember back when I released an improved syndication plugin for rawdog? I used lptest.py as a template for its unit tests, which meant that all of the lptest.py baggage carried over to it. Not cool.

I expect to push out another release of listparser in the very near future, particularly because I found an infinite loop bug in the 0.12 release.

...I mean, I don't think I'm an idiot, but my code seems to have a lot of problems with corner cases...