kay.schluehr at gmx.net
Fri Oct 5 18:09:50 CEST 2007
On Oct 5, 4:12 pm, byte8b... at gmail.com wrote:
> On Oct 5, 5:38 am, Craig Howard <craig.how... at earthlink.net> 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
> 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.
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:
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:
More information about the Python-list