Thanks for the rant! I'm always keen to hear what people like and dislike about unittest.
I'm not inclined to defend the spelling habits of Beck or Gamma, from whom the spelling of the method names was appropriated, but I can at least point out that Merriam Webster lists 'tear down' and 'set up' as perfectly valid alongside their single word counterparts. Were I to write the module again, I would choose a more pythonic naming convention for the method names, but it's sadly rather late for that now.
The inconvenience of testing large data sets with PyUnit is often cited, and I am sympathetic to this. This style of testing diverges from that of true unit testing, and is not conveniently supported by JUnit either. True test-driven development typically specifies behaviour incrementally in a relatively small number of pertinently named and short unit test methods; unittest supports this well, I believe.
Of course there is also a place for larger-scale testing with extended sets of data. It seems reasonable to expect that unittest could be turned to this purpose, and I am investigating what can be done to make life easier in this regard. It could also be argued that a different kind of testing framework might work better for such tests or, perhaps, for your stripped-down individual needs.
Whatever the case, if you have concrete suggestions or further comments I'd be very happy indeed to hear from you and to do what I can to make your life easier.