Ian Bicking: the old part of his blog


In general I agree that the feature set is a little thin in the stock module, but there is enough to get started writing tests quickly. I think it depends on your perspective too. I use Python for functional/system testing of other sytems (not written in Python), and all my previous test harnesses have been centered around data-driven test drivers (along the lines of your DecodeTest example). If you look at the 'common' examples of unit testing today, with JUnit for example, you almost never see it used that way.

I did a couple of things. I made a base TestCase class for data-driven tests. The parameters are passed in via __init__ (exactly like your DecodeTest). There's a matching SuiteBuilder that can read various table formats (ODBC db tables, excel spreadsheets, csv files, etc) that is used to instantiate each test. Each column in the table is a different param (input,output for your example), and you just add any additional columns as needed. For example, I generally have a 'description' column that gets passed to all tests. That get used to change the the result of shortDescription(), so the tests are no longer 'anonymous'. At that point, adding new tests for a particular case is just a matter of adding another line to a spreadsheet (or record in a db table, whatever). Your suite builder can use the extra columns to pick out a single test, or filter out some number of them. Maybe unittest could have provided some of that out-of-the-box, but it really wasn't that much work to tack on.
Comment on Unittest Rant
by Chris Prinos