[Purdue-pm] Beginning Perl: testing
mark at ecn.purdue.edu
Wed Mar 20 15:02:59 PDT 2013
Bradley Andersen wrote:
| this is great - but how do we get people to _actually_ make testing a
| serious, full member of their workflow?
Joe Kline wrote:
| As far as workflow...no clue. I'm still trying to get version control in
| my work flow (I beg off as being a sysadmin so most of my stuff is
| short...until it's not :-)
The most effective way to have people include testing in the workflow
is to not pay them if they don't do it.
_Many_ years ago I used a tool I wrote to do unit testing similar to this
.t 'sin 0' 0
The first arg would be eval'ed and an error message printed if the
result was not equal to the second argument. The terseness and
extensibility of this worked well but it was still a lot of work. And
for non-trivial code it was as much work to write tests as the code
For me, doing better error checking in the code itself (check number of
arguments to subs, right types, in right ranges) and writing clear error
messages is a much better use of my time.
For one-off programs I do the testing during development and when I run
it. For programs I run repeatly I sometimes save all the input and
output and after I make changes to the program rerun it on all the data
and compare it with the output that was checked carefully earlier.
Writing tests doesn't do any good unless you check the output carefully!
If I remember right, TeX had bug(s) in it for years that would have
been eliminated if the original debugging runs were carefully studied.
A "summarize email to the postmaster" program I'm working on now has
current data set of 346 files with a total of 146 million lines that is
used for this regression testing. For example input files are
postmaster.120301, postmaster.120302, ... . The first time I run
test.pl z120301.1 and z120302.1 are created. Running test.pl gives
files that end with .2. Running diff.pl can show differences
automatically and ask to delete old files or can be run and have it
delete all new files that are duplicates of old files. I only backup
xz maximally compressed files and keep the big original files on
non-backed up filesystems on the host the program is run on.
I use version control in my workflow. Emacs has RCS version control
built-in. I prefer to do "rcs -i filename" to initialize, and use "i
filename" and "o filename" aliases to check in and out. I _always_ do a
rcsdiff before checking in to double check I did everything right.
Comments in the source code say when things were checked in and what
version it was. (I don't need anything more sophisticated than RCS for
most the stuff I do.)
More information about the Purdue-pm