Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Test, test, test! (Re: Professional development with Perl - how it's done?)

by roboticus (Chancellor)
on May 29, 2006 at 12:43 UTC ( #552301=note: print w/replies, xml ) Need Help??


in reply to Professional development with Perl - how it's done?

dragonchild already mentioned testing, but I really want to emphasize its importance. You *really* want to have a test suite for your application and it's lowest level components. Once you're comfortable with it, it doesn't slow you down a bit. (Many are even faster with the TDM method.)

But the best benefits (IMO) are the longer-term benefits. You'll be working on dozens of projects, and when you come back to one after not touching it for a year, you'll be amazed at what you don't remember about it. (In fact, I'm occasionally surprised when I'm asked to make changes to something--and I find that *I* wrote it years ago. I totally forgot everything about it.)

In cases like this, you'll find that it's *much* easier to change the system. You go in, read the code, make the changes, and the testing system will remind/alert you to assumptions you made this time that are different than last time. So the better your test coverage, the easier it is to make a patch "that just works".

Another thing I like: You know how sometimes a line of code or a module looks like it could be simplified or cleaned up? So you do it, and you find that it fails in some way. So you put it back the way it was. Then another person comes in and makes the same observation. (S)he comes in, does the same cleanup/simplification, and has to fix it.

Putting in a test makes it easy for you to prevent this and other types of bug regressions. Before you make a patch, make a test that forces the bug to occur, then fix it. Then if someone changes the code to re-introduce the bug, they'll be instantly alerted to it.

My final reason for enjoying test suites: Sometimes you want to make a change to a subsystem. You make it and the test suite shows you dozens of breakages. This allows you to find dependencies that you can correct, so you can further simplify your code. Some of those breakages will be unavoidable, so it will help document some requirements for your subsystem. Also, for fun, you can try to predict the breakage. This can help you keep an eye out for unnecessary interdependencies between subsystems.

There are many other reasons to make testing a primary concern, but I can't think of 'em at the moment. But you'll find them soon enough once you integrate testing into your development regime!

--roboticus

  • Comment on Test, test, test! (Re: Professional development with Perl - how it's done?)

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (7)
As of 2019-12-08 19:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?