In addition to stevieb++'s posting:

Test scripts can do more: You feed your code not only with expected input and test for correct output. But you also feed your code with intentionally bad input and test for correct error handling.

"Intentionally bad input" can be something simple as a string passed to a function that expects a number, or some random garbage instead of a well-formed input file. Or, it can be a test for a known error in an older version.

For example, have a look at the tests that come bundled with DBD::ODBC:

• 01base.t to 90_trace_flags.t, odbc_describe_parameter.t, and sql_type_cast.t are "just" test for the API functions. Load the module, test that some functions basically work.
• pod-coverage.t and pod.t are "documentation tests", that check that everything is documented, and that the documentation itself is syntactically correct. Not much effort for the author, just load and call Test::Pod or Pod::Coverage and let them do their job.
• The most important tests are the rt_XXXX.t tests. They all test for known errors from the bug tracking system, making sure that the overall "make test" will fail if one of the known errors is accidentally reintroduced or "reinvented".

Alexander