Do everything in Java…

Chris via Digitalmars-d digitalmars-d at puremagic.com
Fri Dec 5 06:53:42 PST 2014


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.


More information about the Digitalmars-d mailing list