Andy Lester wrote:
On Jun 19, 2007, at 10:52 AM, Mike Malony wrote:
So I'm working my project, and I've got one other more junior coder with
me.
Has anyone tried writing test files as part of their spec's?
An overview document would also be needed, and some time walking
through the
expected testing. But it sure would be setting clear expectations.
I highly recommend writing your API POD, then the tests, then the code.
That way you're sure all three will be in agreement. Writing tests that
use your API means that you're exercising the API, and your assumptions
about what you want, before you even write any code that uses that API.
A couple of years ago I gave a talk at New Orleans.pm
(http://thenceforward.net/perl/talks/nolaslides.pdf) in which, mostly as
a throwaway joke line, I said that the first thing you do in writing a
CPAN module, once you've set up your directory and file structure, is to
write your documentation.
I said -- much more seriously -- that next you write your tests.
Then, finally, you write your code.
At that time, I sorta, kinda practiced steps 2 and 3, but not step 1.
As I said, it was spoken with tongue planted firmly in cheek.
But, guess what? To the extent that I've been able to determine my own
approach to development, I have increasingly moved in the direction of
doing step 1 first: documentation-driven development.
Or, perhaps more precisely, specification-driven development.
The last couple of modules I've put up on CPAN have started with my
writing 80% of the POD that appears in the posted version.
And the more you do it, the easier it gets.
So, I heartily endorse Andy's position. (But since I followed Andy's
leadership in the Phalanx project, that's not surprising!)
So, assuming you have a good description of the business needs of your
project (admittedly, a big 'if'), why not challenge the junior coder to
describe and document the interface first, then have her/him start
writing, in a test-driven manner, the code underlying that interface?
jimk
