On Fri, Dec 05, 2014 at 02:39:07AM +0000, deadalnix via Digitalmars-d wrote:
> On Friday, 5 December 2014 at 02:25:20 UTC, Walter Bright wrote:
[...]
> >From the article:
> >
> >"Most importantly, the kinds of bugs that people introduce most often
> >aren’t the kind of bugs that unit tests catch. With few exceptions
> >(such as parsers), unit tests are a waste of time."
> >
> >Not my experience with unittests, repeated over decades and with
> >different languages. Unit tests are a huge win, even with statically
> >typed languages.
>
> Well truth to be said, if you don't test, you don't know there is a
> bug. Therefore there is no bug.
Yeah, back in my C/C++ days, I also thought unittests were a waste of
time. But after having been shamed into writing unittests in D ('cos
they are just sooo easy to write I ran out of excuses not to), I started
realizing to my horror at how many bugs are actually in my code -- all
kinds of corner cases that I missed, typos that slipped past compiler
checks, etc.. More times than I'm willing to admit, I've revised and
revised my code to perfection and "proven" (in my head) that it's
correct, only to run it and have it fail the unittests because my brain
has unconsciously tuned out a big glaring typo staring me right in the
face. Had this been in C/C++, the bug wouldn't have been discovered
until much later.
That said, though, for unittests to be actually useful, you sometimes
need to change your coding style. Certain kinds of coding style doesn't
lend itself well to unittesting -- for example, deeply-nested loops that
are very hard to reach into from a unittest, because it may not be
immediately obvious how a unittest might test a rare, tricky
if-condition buried 3 levels inside nested loops. Usually, such code is
actually *never* tested because it's too hard to test -- it's a rare
error-condition that doesn't happen with good input (and how many times
we succumbed to the temptation of thinking the program is only ever
given well-formed input, with disastrous results), too rare to justify
the effort of crafting a unittest that would actually trigger it.
This is where range-based component programming becomes an extremely
powerful idiom -- separating out the logical parts of a complex piece of
code so that there are no longer deeply-nested loops with hard-to-reach
conditions, but everything is brought to the forefront where they can be
easily verified with simple unittests.
But, some people may not be willing to change the way they think about
their coding problem in order to code in a testable way like this. So
they may well resort to trying to rationalize away the usefulness of
unittests. Well, the loss is their own, as the lack of unittesting will
only result in poorer quality of their code, whereas those who are less
arrogant will benefit by developing a much better track record of code
correctness. :-)
T
--
LINUX = Lousy Interface for Nefarious Unix Xenophobes.
