--On 21. Dezember 2007 16:33:34 -0500 Michael Bayer <[EMAIL PROTECTED]> wrote:
On Dec 21, 2007, at 3:13 PM, Rick Morrison wrote:
I think the only way something like this should be done is as a test fixture which decorates classes during unit tests. It would be fairly clumsy to have in production code. If you have coworkers who write broken code, the way you solve that is by having unit tests which will fail when the coworkers in question do something theyre not supposed to. If other people are writing code that sets attrbutes its not supposed to and breaks things, you need more tests to catch those conditions. If youre putting code into production that hasnt been tested, then you need a build process, automated testing, etc. There is definitely a "best practice" here and test driven development is it.
With all respect, this is not a useful answer. Even with tests (unittests and weeks of manual tests) I had the case that a simple programming error (of my own) produced a data disaster after some weeks. There is no 100% test coverage. Tests don't solve all problems. There is sometimes the need for a better security belt.
Andreas
pgpDTXI5voi9F.pgp
Description: PGP signature
