Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jplindstrom (594)

jplindstrom
  (email not shown publicly)

Journal of jplindstrom (594)

Tuesday April 13, 2004
01:56 PM

Test-first, less with existing code

[ #18321 ]

An observation about test-first development.

Once you get used to it, it's pretty easy to stay diciplined and not write a lot of code without having written a test first.

But I have found that once I have a somewhat large body of code already in place (my Worm game) and then go about implementing a new feature, starting with a test isn't always what feels like the most natural thing to do.

Often, I think about the feature, how to solve it. Then I think about the existing code, how to merge the new feature into what's already there. It's often a new line of code in an existing method, maybe a call to a new method, and I start to write that call. The obvious influence on the new method signature isn't an abstract test case; it's the existing code! The context makes it obvious what I want from it, and what parameters I need to pass.

Then I create the method signature and write the POD API and... then I have a tendency to start implementing it! The first method call I wrote feels like a test. Yet it isn't and it doesn't fail.

Maybe it's not important, maybe it's what works for me. Maybe this shouldn't have to be a problem, except I've found that there there is a higher risk I'll end up with no tests at all for the new method if I don't write them early on.

Is it just me?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I solve that by adding a suite of customer tests that make as few assumptions about the internals of the code as possible and test as much of the code in one swoop as possible. Then, when the new customer test or tests fail, I start writing developer tests.