From: Matthew Kerwin <matthew@...>
Date: 2013-02-11T19:33:03+09:00
Subject: Re: elegant way to determine if something is defined

--bcaec554d778e3f29e04d5706eb3
Content-Type: text/plain; charset=ISO-8859-1

Automatic tests are great for catching regressions, and are particularly
useful if your project is large and has many moving parts.  Ideally I write
tests for key boundary conditions (usually after I've written and
hand-tested the module in question, so I can test the tests, as it were),
and, where relevant, for every bug that is discovered and fixed.  In
practice, not so much; but then I don't write buggy code so why bother?*

It's not test driven design, it's plain old regression catching.  When your
codebase get enough modules and enough lines, you don't want to have to
hand test everything that might be touched by a change you make.  Run it
through the tests, catch the obvious gaffes, and focus on the task at
hand.  If a new bug crops up, add a new test so it doesn't happen again.

* yep, really, truly, my code is all 100% absolutely perfect. It's *meant*
to do that.
-- 
  Matthew Kerwin, B.Sc (CompSci) (Hons)
  http://matthew.kerwin.net.au/
  ABN: 59-013-727-651

  "You'll never find a programming language that frees
  you from the burden of clarifying your ideas." - xkcd

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra">Automatic tests are great f=
or catching regressions, and are particularly useful if your project is lar=
ge and has many moving parts.=A0 Ideally I write tests for key boundary con=
ditions (usually after I&#39;ve written and hand-tested the module in quest=
ion, so I can test the tests, as it were), and, where relevant, for every b=
ug that is discovered and fixed.=A0 In practice, not so much; but then I do=
n&#39;t write buggy code so why bother?*<br>
<br></div><div class=3D"gmail_extra">It&#39;s not test driven design, it&#3=
9;s plain old regression catching.=A0 When your codebase get enough modules=
 and enough lines, you don&#39;t want to have to hand test everything that =
might be touched by a change you make.=A0 Run it through the tests, catch t=
he obvious gaffes, and focus on the task at hand.=A0 If a new bug crops up,=
 add a new test so it doesn&#39;t happen again.<br clear=3D"all">
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">* yep=
, really, truly, my code is all 100% absolutely perfect. It&#39;s *meant* t=
o do that.<br></div><div class=3D"gmail_extra">-- <br>=A0 Matthew Kerwin, B=
.Sc (CompSci) (Hons)<br>
=A0 <a href=3D"http://matthew.kerwin.net.au/" target=3D"_blank">http://matt=
hew.kerwin.net.au/</a><br>=A0 ABN: 59-013-727-651<br><br>=A0 &quot;You&#39;=
ll never find a programming language that frees<br>=A0 you from the burden =
of clarifying your ideas.&quot; - xkcd
</div></div>

--bcaec554d778e3f29e04d5706eb3--