<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>testing &middot; Arguable Intelligence</title><link>https://ojmason.net/tags/testing/</link><description>Personal musings on computational linguistics, AI, sailing, and generated fiction.</description><language>en-gb</language><managingEditor>Oliver Mason</managingEditor><webMaster>Oliver Mason</webMaster><lastBuildDate>Tue, 17 Jul 2012 00:00:00 +0000</lastBuildDate><atom:link href="https://ojmason.net/tags/testing/index.xml" rel="self" type="application/rss+xml"/><item><title>Every Test is Valuable</title><link>https://ojmason.net/every-test-is-valuable/</link><guid isPermaLink="true">https://ojmason.net/every-test-is-valuable/</guid><pubDate>Tue, 17 Jul 2012 00:00:00 +0000</pubDate><category>programming</category><category>testing</category><description>After reading Graham Lee’s Test-Driven iOS Development; (disclaimer: affiliate link) I have (again) adopted a test-driven approach to software developing. Whenever I create a new class I write a bunch of tests exercising the class’ properties. One might question the value of this, because there is not really any reason why those should not work. However, having such a test in place just uncovered an as-yet unnoticed bug I introduced in a project.</description><content:encoded><![CDATA[<p>After reading Graham Lee’s <a href="http://www.amazon.co.uk/gp/product/B007RNK0W6/ref=as_li_ss_tl?ie=UTF8&amp;camp=1634&amp;creative=19450&amp;creativeASIN=B007RNK0W6&amp;linkCode=as2&amp;tag=phrasysnlp-21">Test-Driven iOS Development</a>; (disclaimer:
affiliate link) I have (again) adopted a test-driven approach to
software developing. Whenever I create a new class I write a bunch
of tests exercising the class’ properties. One might question the
value of this, because there is not really any reason why those
should not work. However, having such a test in place just uncovered
an as-yet unnoticed bug I introduced in a project.</p>
<p>Originally the class property in question was going to be set in
the <code>init</code> method, so I tested for the presence of the property
after creating an instance of the relevant class. Easy pass. Weeks
later I did something (and forgot to run the test suite). Today I
did something else, and this time I did run them. Hey presto, failed
test. And completely unexpected, because it was the property
exercising one. How on Earth did that happen?</p>
<p>Upon closer inspection I tracked it down to a refactoring, where I
extracted some code from <code>init</code> as there were now multiple ways an
object could be initialised. The failing code was part of that, and
I realised that it was called from the new <code>initFromFile:</code> method,
but <em>no longer from the default initialiser</em>. Easy mistake to make.
And had I run my test-suite more consistently, my application would
not have been with a potential bug in the meantime.</p>
<p>What did I take home from this?</p>
<ul>
<li>Even Mickey-Mouse-tests are valuable. No test is too small to be useful
(provided it’s actually testing something valid).</li>
<li>The test-suite should really be run after every change. I’ll have to check
if I can get Xcode to run them automatically after each compilation…</li>
</ul>
<p><em>Update</em>: Since I stopped doing much iOS or Mac OS work, I no longer used Xcode.
And I&rsquo;m not missing it :)</p>
]]></content:encoded></item></channel></rss>