At 07:48 2003-04-26 -0400, Doug Essinger-Hileman wrote:
Is the test bench suggested on Timo's procmail page
(http://www.uwasa.fi/~ts/info/proctips.html#testbench)
a good one, or is there a better bench to us?
Better is a subjective thing. Timo's is suitable if it is suitable for
what you're doing (it is definatley better than not having a testbench at
all). I'll say that I use a different one myself, which is documented in a
link from the disclaimer you can reach in my .sig. I go so far as to
redefine SENDMAIL, and have a sendmail.sh script in my "sandbox" (what I
call a test bench). This means that recipes which would normally forward a
message, or which explicitly invoke sendmail (though you should ALWAYS do
this through the $SENDMAIL variable), will instead run the sendmail.sh
script, which dumps the message into a file, along with info on the params
it was passed. This better isolates your testing, since nobody likes
receiving autoreplies and crap from some nimrod testing a mailfilter...
If Timo's is the one to use, then let me ask where I should put the
mail.msg to be fed to the test. In one's home directory? or in the
test directory?
In Timos example, mail.msg would be in whatever directory was current at
the time you invoked the proctest script (the proctest.rc file itself can
be elsewhere, and the proctest script can be anywhere in your path, or
manually invoked with a prefixed path).
I don't personally use a script to invoke my sandbox, because my individual
test needs vary from one test to the next. I just run it however seems
appropriate based on what I'm doing at the time.
For instance, when extracting messages previously identified as spam, to
run through a filter to see how well it'll still identify them:
gzip -dc < ~/Mail/200304/spam.gz | formail -s procmail -m sandbox.rc
(this because I locally archive into gzip files)
or, if I'm simply taking a _single_ test message and throwing it at the rc:
procmail -m sandbox.rc < mbx/test.msg
(I personally have a subdir where I keep a variety of test message files
which I can tweak and throw at filters).
The bottom line is, it depends on how you set things up. Ultimatley, your
testbench/sandbox/etc should set up a similar environment to what your
~/.procmailrc does (before delivery/filter recipes), so that any filter you
test in the testbench will act the same as if it were running in your real
.procmailrc. So, if you define a number of standard variables, define them
in the sandbox.rc too.
The whole of my own testing setup is in a separate subdir from the rest of
my procmail material. there, I have a save subdir with useful code
fragments from previous tests, saved test messages and mailboxes, and some
other material. The only files residing in the directory itself are:
sandbox.rc (NOT OWNER WRITEABLE - makes changing it more
of a deliberate action)
sendmail.sh
filter.rc (the file I put my filter into)
Having the test framework separate from the individual filter makes for a
more consistent test - you're not boffing the basic setup of the sandbox
each time, and the actual filter is more just as it would be when you go to
migrate it into your regular procmail config, with nothing to strip out of
the individual file to make it work properly in your .procmailrc.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail