[article] Language Design Deal Breakers

[H. S. Teoh]

On Sat, May 25, 2013 at 10:28:24PM -0400, Nick Sabalausky wrote:
[...]
> But, for much the same reason, I am somewhat with the author on
> unittests. I definitely find them very important and worthwhile, but
> my experience is in-line with "writing unit tests **for everything**
> very frequently fails the bang-for-buck test" (emphasis added).
> 
> In something nicely static-typed like D, most tests never end up
> failing, and actual applications do end up implicitly testing a heck
> of a lot anyway. Of course, this doesn't imply that unittests aren't
> extremely worthwhile (and I don't think even the author was claiming
> otherwise), and unittests have indeed helped me a good deal, but I do
> think they definitely have a "point of diminishing returns".

Hmm. My experience with D's unittests is that I'm writing code with
unittests nowadays *only* because they were built into the language. I
know it's a bad attitude to not want to write unittests, but I just
can't be bothered to switch gears every now and then between writing
code and writing unittests if the latter requires switching to a
different file / different directory / different language, and if extra
effort is required to run said tests.

Having them built into the language though, completely changed the
equation. I'm actually *encouraged* to write way more unittests than I
ever would have, simply because having them as part of the language
makes it possible to not have to mentally switch gears -- I often find
myself writing unittests *as* I'm coding up a function. With the code
fresh on my mind, I can immediately write a unittest for a boundary
condition that just occurred to me, and immediately after writing a
function, I can write a unittest to check that it actually does what I
think it does -- I don't have to leave the D code to use another
framework and setup an external scaffolding for the test; it's right
there waiting to be used. Furthermore, having all these unittests pass
even after an initial draft of my code gives me a lot of confidence that
the code is actually correct, as opposed to my past experience where I'd
write the code, then run a few tests by hand, then said to myself "OK it
looks good", then proceed to make more changes, but afterwards I can't
be bothered to repeat the previous tests, so by the time I've gone
through 5-6 change cycles, I no longer have confidence that the earlier
tests still pass. (And I have no way of checking 'cos I had been too
lazy to write external unittests for them and now can no longer remember
every single boundary condition that I had tested for 5 iterations ago.)

D's unittest blocks have singlehandedly converted me from a
code-by-faith person full of every excuse to *not* write unittests, to
somebody habitually writing unittests. The quality of my code has
improved by leaps and bounds. And I like writing exhaustive unittests,
because they give me the confidence that 50 iterations down the road,
the obscure corner cases in my code are still working correctly, and no
subtle bug has crept in since. I like having that level of confidence in
my code, esp. in pieces that get reused a lot. It saves a LOT of
headaches and time spent trying to track down obscure bugs.


> That said, good unittesting tends to be much more important for
> libraries. And in dynamic-land, then yea, you probably are royally
> screwed if you haven't pedantically unittested the crap out of every
> single line of code, under every context and runtime type imaginable.

Yeah no kidding. If I had a penny for each time some PHP or JS (or even
Perl!) code broke horribly because somebody passed in the wrong type in
a function argument, I'd be a millionaire. Worse yet, too much of said
code often have no documentation as to what argument types are expected,
leaving you to guess by trial and error (and watching the code blow up
in hilarious or not-so-hilarious ways).


T

-- 
One disk to rule them all, One disk to find them.
One disk to bring them all and in the darkness grind them.
In the Land of Redmond where the shadows lie.
-- The Silicon Valley Tarot