Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

Re: Testaholics Anonymous (or how I learned to stop worrying and love Test::More)

by mstone (Deacon)
on Apr 02, 2004 at 23:02 UTC ( #342176=note: print w/replies, xml ) Need Help??

in reply to Testaholics Anonymous (or how I learned to stop worrying and love Test::More)

You should probably take a look at the book _The Capability Maturity Model for Software Development_, published by the Software Engineering Institute. Tests are all well and good, but if they don't improve your development process, you're not getting as much benefit out of them as you should. You should also start tracking which specific tests identify bugs each time you run your test suite.

Bugs don't occur randomly, they occur for specific reasons. Your test suite will help you locate the reasons behind the bugs, and then you can deal with each cause in a way that makes sure you never need to test for it again.

Case in point -- I used to forget to write the return() statement at the end of the occasional function:

package Thingy; sub new { my $O = bless {}, shift; [lots of value setting here] [and oops, no return() statement!] }

When I started tracking my mistakes, I discovered that problem, and made a trivial change to the way I write code. Now, every function I write starts off looking like so:

sub func { return ($result); }

Then I go back and fill in all the code necessary to generate $result. That simple habit has saved me no end of headaches and bug fixes. I also put my constants first in conditionals:

if (3 == $x) { [whatever] }

because typing '=' instead of '==' will create a syntax error, not a valid (and invisible to human inspection) assignment statement. (Admit it, you had to read that last sentence twice to see how the two strings were different, didn't you? ;-)

Writing tests is like optimizing your code. Yes, it's fun, but you can invest massive amounts of effort in it, and a test that doesn't locate bugs is a waste of effort. 80% of the payback will come from 20% of your test suite, so figure out which 20% that is, and focus your efforts there.

Create a list of tests that have actually detected bugs at some point in their existence, and use that set as your day-to-day test suite. Then run the whole megillah once every week or two just to see if anything new has crept in. When you write a new test, put in the big once-a-week set, but don't move it to the daily-use set until it actually locates a bug.

Once you do find a bug, try to find a way to improve your coding practices so you don't keep repeating the same mistake over and over again. Keep running the relevant tests for a week or two to see if the improvement has worked, and if it does, demote that test back to the once-a-fortnight set.

That will keep your basic test suite slim while still giving you the option of being comprehensive, but it will also help you zero in on which parts of your code really need to be tested.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://342176]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (7)
As of 2021-04-14 13:35 GMT
Find Nodes?
    Voting Booth?

    No recent polls found