From: David Vallner <david@...>
Date: 2006-11-03T12:26:36+09:00
Subject: Re: ruby programming best practice

--------------enigA9AAE955C5D04EE22DA9D078
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

James Edward Gray II wrote:
> On Nov 2, 2006, at 4:27 PM, David Vallner wrote:
>=20
>> Richard Conroy wrote:
>>> On 11/1/06, Shannon Fang <xrfang@hotmail.com> wrote:
>>>> Experts, please tell us, your best practice, facing this "intrinsic"=

>>>> problem
>>>> of dynamic languages...
>>>
>>> Use Unit Tests.
>>>
>>> With automated unit testing, the benefits of static typing, bounds
>>> checking,
>>> null checking etc. start to disappear, as you typically write tests f=
or
>>> these
>>> scenarios anyway.
>>>
>>
>> <rant> <!-- Hide the women and children. -->
>>
>> The benefits disappear as you reimplement them in test cases anyway?
>> Insert comment about wheel reinvention here.
>=20
> I quit reading right here.
>=20
> It's *not* reimplementation!
>=20
> You need to be testing your software anyway, even if you are using the
> perfect language that protects you from all your errors.  Since you're
> doing that anyway, this is just a free side effect for your good habits=
=2E
>=20

That's what the original quote states though. "You typically write tests
for these scenarios anyway.", amongst those scenarios being some that
can be checked using static analysis in a suitably more predictable
language. If you're using a dynamic language, and covering checks for
those scenarios in unit tests, then you're reimplementing what a
contract-verifying compiler / runtime would catch in them, quite simply
because without such a compiler / runtime you don't have much choice if
you want your code to be robust along those axes. In and of themselves,
unit tests are (supposed to be) a complement to (substitute for the
absence of) language-provided unit contract checks - since they're
arbitrarily user-defined, they are to be used to check dynamic aspects
of those contracts that statical analysis (if there is any) can't.
Generally the unit testing methodology gets more awkward when you need
to test complex emergent behaviour that comes from the cooperation of
these units, and equating them to "testing your software" is just
misleading.

If you gain enough coverage for dynamic unit contracts, I'll admit it's
probably safe to assume that you have the more trivial checks that
statical analysis can do covered - in that case you can do away with
anything that would be reimplementing a compiler's checks. However, such
coverage takes nontrivial effort to create and maintain, and usually at
least I want to be able to reason on a code unit's correctness at least
to some extent while expending no / minimal effort on test code for the
"D'oh" type of error. For example, I'd very much like if I could tag a
variable to disallow assigning a nil into it and raise an exception when
that happens -immediately-, instead of getting a NME someplace else in
the code. I'd be hard to convince removing that check into a unit test
would be more concise than having language support for it.

David Vallner


--------------enigA9AAE955C5D04EE22DA9D078
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFSrbiy6MhrS8astoRAmWBAJ4qOlBVHTs48ghvT/aNAL7n79kdZgCaA/j6
UQeo+B8nHWJwxCrYAh5Vr34=
=3BdU
-----END PGP SIGNATURE-----

--------------enigA9AAE955C5D04EE22DA9D078--