In principle, stating a problem is a trivial exercise: someone can't do something. It can be made wonderfully complex, however. The root cause of the complexity could be a fundamental unwillingness to state the problem without including technology hints like "database" or "hierarchy" or "project management" or "change control".

While some spread-sheet use is civilized numerical stuff, and other spread-sheet use is merely personal organization, too much spread-sheet use is the poor-person's database management system. I call it the Spreadsheet Schema (SSS), different from normalized relational schema and star schema.

There is a serious problems with people using spreadsheets …

"Polymorphism is nice as well, although I can't grok (yet) why this is necessarily not part of non-OO things. I'm not clear that it goes with the strong binding of state and method in a class."

Polymorphism isn't necessarily part of OO. Python actually has polymorphic functions outside of class …

testresources http://www.robertcollins.net/unittest/testresources/ purpose appears to be to manage the resources used by a test suite.

Adding this resource management context extends the Test Suite to optimize tests around the resources. This can reshuffle the TestCases to minimize SetUp's. This can be useful in contexts where …

SubUnit's http://www.robertcollins.net/unittest/subunit/ purpose appears to be to manage testing via subprocesses.

Consequently, it can run external tests not in Python, it can fork a subprocess to manage the Fixture in an isolated process.

Adding this subprocess execution context extends the Test Runner implementation of the …

Trial is not really a stand-alone unit test framework. It is an extension to unittest focused on the testing needs for the Twisted framework.

The Trial how-to http://twistedmatrix.com/projects/core/documentation/howto/testing.html has some information. More valuable, perhaps are the API documents http://twistedmatrix.com/documents …

A wiki page on Python testing tools http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy identifies a number of additional unit testing tools. The wiki page provides a handy summary. I'll examine these in light of the Beck Unit Test design patterns to provide a little more detail on what they really do …

The "correct" answer is to fully normalize the design and get away from a mixed bag of columns and nulls. The MESS is bad from every perspective, except query performance. A semi-normalized design that separates the STATE CHANGES from the ESSENTIAL DEFINITION is an optimal design in many respects.

Here …

Experimental results depend on details of the database server and the data model used. Actual application software may have other confounding problems that make these results less dramatic or more dramatic when applied to a existing application design.

I compared three table designs described in a previous posting Normalization Experiment …

Fragmentation & similar is sometimes a storage problem in I/O generated, vs. the gross space consumed. This distinction didn't leap out at me.

Performance degradation and storage expansion are closely related, but only for certain kinds of queries. Full table scans are penalized by sparsely used storage. Individual row retrievals …