On Friday, 5 December 2014 at 13:06:14 UTC, H. S. Teoh via
Digitalmars-d wrote:
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
I wish it was arrogance or unwillingness to change, because you
can work on that. If I were arrogant or unwilling to learn, I
wouldn't have gone for D which keeps kicking me in the backend
relentlessly.
I introduced uint tests a while ago (because it's sooo easy in D)
but I've failed to maintain them. I found out that most of the
bugs weren't caught in the unit tests but where somewhere else
further down in the logic (more on that later). I repeat my point
that we put into the unit tests what think will or won't work,
just as you said:
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.
Unit tests are just another way of "proving in your head". In D
I work a lot with components and ranges, and I f**king love it.
While it is true that this approach to programming makes each
unit easily testable, I've found out that they are no guard
against major f**k ups further down in a program's logic. At the
end of the day, you have to design a general test suit for the
whole program and see if it works. So why bother to test every
unit, which may work perfectly fine on its own, when you have to
test the whole shebang anyway.
As I said, I'm not against unit tests and I use them where they
make sense (difficult output, not breaking existing tested code).
But I often don't bother with them when they tell me what I
already know.
assert(addNumbers(1,1) == 2);
I've found myself in the position when unit tests give me a false
sense of security.
What Russel said, that we should think about breaking the code.
It's true, but extremely hard to do when you _create_ something.
You create something to make it work and not to destroy it. It
also kills your imagination. It's like writing a thesis when you
spend most of the time preparing for possible attacks from the
examiners rather than thinking innovatively. I don't think any
technology would have been invented, if people had thought of how
to destroy it at the same time. That's what you (and others)
think about after you've created it.
