and this:
http://djangosnippets.org/snippets/1949/

Steal away. You’re allowed to make any use of this code that you wish, with or without attribution. How’s that for a license?

Either that or start a new project on Github, with this in it.

Unfortunately, the same time/resource pressures that gave rise to UML and Agile methdologies – have tended to favor test cases being generated by separate individuals not intimately familiar with code construction – at the same time that new programming paradigms have started to “abstract away” topology complexity and these basic rules.

Modern automated testing, in addition, has often enabled the practice of SQA leaning heavily toward automated regression testing being “bolted” directly on unit testing as a (very) poor substitute for best practices.

Sometimes system integration testing is eliminated entirely as a regiment – being replaced with “end-to-end” system testing which is not precisely the same thing, as in, each unit tester should be performing unit integration testing with those components that provide functional interfaces to their “unit” prior to any “end-to-end” system test.

I’ve seen massive projects considered to have been sufficiently tested because they’ve passed a “majority” of their (non-descript) “tests” – by clueless managers – who are always looking for a way to shorted the cycle – so they can jam-in some crowd-pleasing feature and establish their dominance over the process and collect their year-end bonuses.

Before I establish my own unit testing regiment on a “contract gig” – I judge the sophistication and maturity of the overall SDLC – before I set the “rigor” of my approach. If unit-integration, stress, regression or other important aspects are missing – I “beef-up” my unit testing regiment – sometimes including my own test-beds and tools – to ensure that my own code is sufficiently bullet-proof that I don’t spend my time debugging the SDLC – instead of my code.

As far as your “clunky code” technique – It’s a sound one – as is developing portions of conditionalized code that are deliberately “fragile” – such that they fail “cataclysmically” in the event that some (very) basic assumption is violated during unit or system integration…As you have clearly stated – It’s better to catch problems with your code, your neighbor’s or the entire process – at the unit-level – before all of the “shirts” are standing around, glad-handing each other on their mutual success.

Corollary: Take all vacations during peak periods of system instablity. It’s the only way they’ll notice that you’re gone. If they object, setup an immediate meeting to “negotiate your compensation”. Bring a handgun and sport a crewcut.

I work on the Cloud Servers team at Rackspace. We think we know what happened. Could you please contact me at erik dot carlin at rackspace dot com. I’d love to follow up with you, confirm our hypothesis, and get some feedback from you on how you’d like to see it work.

Thanks for calling us out. We are constantly improving cloud servers and need customers to make us aware of issues and keep us honest.

Regards,
Erik Carlin
Director of Product