"Sean Russell" <ser / germane-software.com> schrieb im Newsbeitrag
news:83173408.0405240553.326b2587 / posting.google.com...
> "Robert Klemme" <bob.news / gmx.net> wrote in message
news:<2hc380Fa9p38U1 / uni-berlin.de>...
> > An automated system (supposed it *could* be done) would yield the
false
> > impression that one would not have to do anything manually any more.
That
> > could lead to more bugs because of less attention.
>
> Ah.  By that logic, unit testing is bad, because it gives you the
> false impression that your code works just because it passes the
> tests.  Therefore, unit testing leads to more bugs.

Not exactly: With unit testing you control the coverage, i.e., you decide
about the expected behavior and write tests for exactly this behavior.  So
you *know* what is covered.  Of course, you can miss out something, but
you can add tests as you find those holes.  You could not control type
checking other than switching it on or off and you don't know how much of
the code is really covered by it.

>  Real programmers
> walk through each line of their code on paper, evaluating each
> statement in their head, right?

No, I do a formal proof of every method in my head. ;-)))

> > > And, no, I won't have to look at 100% of the code to find the 10%.
> > > I'll notice the 10% when it fails -- just like I do right now.
> >
> > Might be too late then - especially for libs.  IMHO it's more
efficient to
> > rely on tests.
>
> You will never test everything.  It is a simple fact: there will
> always be some case that you simply didn't write a unit test.  This is
> the greatest limitation in unit testing: it relies on the programmer
> to anticipate errors, and many bugs are unanticipated.

How true!

> If you had an entirely closed system, it is theoretically possible
> that you could write unit tests for all possible cases -- but, then,
> you'd have a matrix of all possible answers and you wouldn't need the
> program, right?

That matrix would not make the program superfluous, because - depending on
the problem - you still need the computer to do something.  You can't omit
a car engine control software just because you know how it will behave in
every situation, can you?

> Unit testing is, perhaps, the most powerful development tool available
> to programmers, but it isn't the only tool.  I welcome with enthusiasm
> any improvement in the debugging tools available to me.

Yes, of course.  I'm completely with you at that point.  It's just that I
doubt effort and effect are balanced on this one: the implementation of
such a feature is quite complex (and error prone in itself :-)) but the
use is IMHO quite limited because of Ruby's dynamic nature.

Regards

    robert