On Oct 5, 4:12 pm, [EMAIL PROTECTED] wrote: > On Oct 5, 5:38 am, Craig Howard <[EMAIL PROTECTED]> wrote: > > > Brad: > > > If the program is more than 100 lines or is a critical system, I > > write a unit test. I hate asking myself, "Did I break something?" > > every time I decide to refactor a small section of code. For > > instance, I wrote an alarm system in Python for a water treatment > > plant. If the chlorine, pH, or turbidity are out of spec, an email > > message is sent to the plant operator's pager. Because of the nature > > of the alarm system, extensive field testing was out of the question. > > Unit testing was the only way to ensure it worked without disrupting > > the plant operation. > > > Craig > > Thanks to all for the opinions. Just to clarify, I have nothing > against testing. I like doing it. I catch a lot of bugs! I dislike the > formality of the unittest module. It's unyielding. It makes testing > difficult unless your code is written with testing in mind from the > start. > > I maintain old code... code written a long time ago, before unittest > was popular. Getting unittest to work on that is difficult at best. So > we do informal testing ourselfs. The end result is the same... bugs > are squashed before the code is placed into production. Many times, we > find bugs as soon as we write a test! > > Thanks again for the advice. > > Brad
Just one recommendation. I don't know your project and remote diagnostics is usually more funny than usefull, but there is a body of literature about dealing with legacy code, for example: http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052 Of course Micheal Feathers talks constantly about putting systems under test, exposing code for testability and lots more that goes beyond code & fix. Here is some article of the same author: http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf Kay -- http://mail.python.org/mailman/listinfo/python-list
