<?xml version="1.0" encoding="windows-1252"?>
<node id="480790" title="Re: When test-driven development just won't do" created="2005-08-04 08:17:58" updated="2005-08-12 10:30:04">
<type id="11">
note</type>
<author id="268515">
xdg</author>
<data>
<field name="doctext">
&lt;p&gt;Minor suggestion on the can_ok, based on some code I was recently writing:
&lt;/p&gt;
&lt;code&gt;
no strict 'refs';
ok( defined *{$CLASS."::".$method}{CODE}, "$CLASS has $method")
&lt;/code&gt;
&lt;p&gt;At issue for testing is always whether a test really tests what you want.  In this case, for example, &lt;code&gt;can_ok $CLASS, $method&lt;/code&gt; isn't what you want if you want to know whether a method exists in a particular class.  I find that test-driven development works for me because it makes me specify more clearly what behavior I want before I go write the code.&lt;/p&gt;
&lt;p&gt;For the first general case you raise, my view is that one writes the test as soon as one knows what the expected behavior is.  Until that's defined, playing around is OK.  For the second case, while I've not had to tackle that kind of project, if I did, I'd approach it top-down, not bottom up.  E.g., write a  "total program" test that takes certain input and gives the actual existing output, then start to work on macro testing of major subsystems, etc.&lt;/p&gt;



&lt;div class="pmsig"&gt;&lt;div class="pmsig-268515"&gt;
&lt;p&gt;-xdg&lt;/p&gt;
&lt;p&gt;&lt;small&gt;&lt;i&gt;Code written by xdg and posted on PerlMonks is &lt;a href="http://creativecommons.org/licenses/publicdomain"&gt;public domain&lt;/a&gt;. It is provided &lt;b&gt;as is&lt;/b&gt; with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.&lt;/i&gt;&lt;/small&gt;&lt;/p&gt;
&lt;/div&gt;&lt;/div&gt;</field>
<field name="root_node">
480680</field>
<field name="parent_node">
480680</field>
</data>
</node>
