Moin,
I think I found something to kill some time on: Cleaning up the test
framework. Currently each test is created by copy-and-pasting some old one
as a skeleton and modify it according to the needs. This introduced some
kludgy stuff, like the three line preamble each test has and sometimes the
chdir("t") stuff which shouldn't be necessary because that's already done
in sa_t_init().
I'd like to replace the current medley with some cleaner framework with
which its easier to write tests.
The first change would replace the current three-line preamble with one
single 'use SATest'. That's possible with the attached patch and some
additional code. This will mean that the executable attribute on all those
tests (which you guys always forget to set anyway :) will disappear.
Instead there will be a short script called "run" or something which you
can use to execute single tests.
The next thing is that the tests are currently run in more or less random
order (yeah, alphabetic but logically randomly). I'd like to introduce a
schmema like the one we have for the rule files, ie. names like nn_test.t
where nn is a number, the first digit roughly indicating some group (basic,
spamd, bayes, ...), the second the precedence within that group.
Then its time for bug 3818 which actually led me to this plan :) I'm not
sure if that should be based on the grouping mentioned above or some
additional keywords for each test, but I'd like to make the disabling (and
enabling) of single tests more flexible. So, say, some Bayes SQL test
could have the keywords "bayes sql net" -- only if all three keywords are
enabled, the test is run.
I hope a slimmer and documented (and thus easier to understand) framework
for the tests will make people write more tests. On the other hand do I
not want to increase the number of tests run for the mere mortal who
installs SA via CPAN and already has to wait ages. So I'd like to keyword
some of the tests as "basic" (or whatever keyword) and only those tests are
run per default. All other tests would be used by us devs, people who we
ask to debug one of their bug reports aund the BuildBots.
Oh, and another thing is separating the real temp data from the log data, so
the latter is better to find. Also make it easier to use the dirs by
feeding some vars to the scripts.
Plus maybe some helper routines like ok_if_equal() (yeah, I've been working
a lot with JUnit lately).
And I almost forgot: Making the scripts actually compliant with
Test::Harness -- currently any unknown output on stdout is just ignored but
the man page has a big fat warning that this might change in future. And
we really ought to give reasons why tests are skipped.
Any other things you'd like to see?
Cheers,
Malte
--
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
<http://www.catb.org/~esr/faqs/smart-questions.html>
Index: Makefile.PL
===================================================================
--- Makefile.PL (revision 106734)
+++ Makefile.PL (working copy)
@@ -1066,8 +1066,23 @@
clean_MY_globals($self);
return join("\n", @code);
}
-
+
+sub MY::test_via_harness {
+ my $self = shift;
+ my @code = split(/\n/, $self->SUPER::test_via_harness(@_));
+ init_MY_globals($self);
+
+ foreach my $line (@code) {
+ # Insert an -It before the -e switch, keep the quoting.
+ $line =~ s/(\s["']?)(-e)(["']?\s)/$1-It$3$1$2$3/;
+ }
+
+ clean_MY_globals($self);
+ return join("\n", @code);
+}
+
+
sub MY::postamble {
my $self = shift;
my $code = "";
