As you can see, but putting things into packages, we can make nicely
encapsulated functions or methods. By depending only on what they
accept and not having side-effects, it's very easy to write tests for
them. As a result, when you're testing some other code that
accidentally passes in a DBI object to get_customer(), it blows up
nicely, you find out from your tests (instead of your customers calling
to complain) and it's easy to fix.
Once I started testing, my code quality and overall productivity have
gone up quite a bit. Quality goes up because I discovered that code
which is easy to test is generally better code. Productivity has gone
up because developing higher quality code and constantly refactoring
means that my code base is much easier to work with. I'm rarely
"hacking around problems".
Cheers,
Ovid
Thank a lot Ovid.... Your explanation enlightened me to the existance of
the variousTest modules...
Test::Harness <http://perldoc.perl.org/Test/Harness.html>
Test::Simple <http://perldoc.perl.org/Test/Simple.html>, Test::More
<http://perldoc.perl.org/Test/More.html>, Devel::Cover
<http://search.cpan.org/perldoc/Devel::Cover>
Test::Builder <http://perldoc.perl.org/Test/Builder.html> for building
your own testing library.
Test::Unit <http://search.cpan.org/perldoc/Test::Unit> is an interesting
XUnit-style testing library.
Test::Inline <http://search.cpan.org/perldoc/Test::Inline> and SelfTest
<http://search.cpan.org/perldoc/SelfTest> let you embed tests in code.
I'll be investigating these in the near future (a lot to read and
digest) and hopefully they will help me in testing my own modules.
By the way, are the use of these Test modules just as appropriate to use
in testing interactive CGI scripts as they are for scripts with no user
interfaces?
Thanks again
Tony
