unit testing

[Kay Schluehr]

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
> 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