On Mon, 8 Jul 2002, Andy Wardley wrote:
> It does now, but few of the stand-alone tests have names. But all
> the tests run by test_expect() do use names, e.g.
> ok 4 - template test 1 processed OK: Hello World\nfoo: [% foo %]\n[% DE...
> ok 5 - matched expected
Ah, but that's just the template text isn't it? I want to have names for
the tests so I know what they're trying to test (i.e. what the *aim* of
the test is.) Am I missing something (I frequently do.) I was thinking
of a
-- test --
-- name: fred --
or even
-- test: fred --
extension to the current language
> I tweaked Template::Test a while back to behave in a (fairly) compatible
> way with Test::Simple/More. For example aliasing is() to match(), and
> allowing the third argument (test name) to ok(), is(), etc.
When I mean compatible I mean that they can be run under the same test
script, and that they'll respect each other's output. In other words,
that they use Test::Builder as a backend to abstract out the actual
printing of data to screen.
> > >From what I can see from playing around inside Template::Test it'd be
> > really really hard to adapt it to work with
> Yes. In particular, the script has to parse the input and split it into
> -- test -- / -- expect -- blocks to determine how many tests there are.
> Multiple this number by 2 (first test that process() works ok, second
> that output matches expected), add any tests that have already been
> run (ok() caches results), and also add any that have been pre-declared
> as following after test_expect() ($EXTRA), and a few others that accumulate
> along the way.
>
> Then, and only then, do you know what the plan is.
Yep, which is why translating it to Test::Builder is non trivial. I tried
doing it before I sent the first message, realised it was non-trivial and
then thought I'd better try another approach. It's Perl - it's not meant
to be hard ;-)
> One of the things I dislike about Test::More et al is having to pre-
> declare a plan. I don't like having to change this value each time
> I add a test. I'd much rather have the script work out how many tests
> it's got and do the math for me.
But if your script is working out in advance how many tests it's got to
do, then you run the risk of your script dieing when you're declaring the
tests. If you don't know how many tests you're going to run (or you can't
be bothered to work it out) you could always do a quick
Template::Test2 qw(no_plan);
at the top. Though this might cause problems if you've got an old version
of Test::Harness.
> Another benefit is that you can add a
>
> -- start --
> or
> -- stop --
>
> anywhere in the test script, and the module does the right thing in
> determining the new number of tests. I would get very irritated if
> I had to jump up to the top of the file and change the plan every time
> I did this. Which is often :-)
When I'm creating test scripts I tend to ignore the warnings about how
many tests I was supposed to run (I run the test scripts with "perl -Ilib
t/scriptname.t", not with a makefile.) Only when everything is working
fine do I change the script to report the correct number of tests.
> So any change to the module should support this automatic plan generation.
Right, this is more tricky. I could just have one test for the entire
test_expect block...but that's not really a good idea.
> [instroducing another manditory module]
Well, if we don't want to force them to download something else from CPAN
then the choices are (in order of difficulty)
a) Give up, use the current example instead and use the free time to
go watch some Buffy on TV / Go boarding / etc
b) Bundle Test::Builder (and probably Test::More) with the Template
Toolkit so we always have them at hand.
c) Write code that provides a thin emulation for the few Test::Builder
and Test::More functions that we want to use if the real versions
aren't available.
Let me expand a little on option c. This code would be basic and be as
simple as possible to satisfy Test::Harness. Basically it would create a
"ok" and "not ok" type message and have nothing else. If you want human
readable debug information, you can install the proper modules and find
out that way. Hopefully since the Test::Harness interface to these few
functions won't change (or shouldn't when 5.8.0 goes live anyway) the
compatibility should hold
I'm not sure which is the best option, but for tonight at least I'm going
to do a) ;-)
> move all the current cruft out of Template::Test into
> Template::Test::Crusty (or some other better name), and hack the new
> Template::Test to use Test::More/Simple if available, falling back on
> Template::Test::Crusty to provide the ok()/is()/etc mechanism otherwise.
Again, that forces me to write a compatible system, which is just too hard
to do. I'd hope for a separate module that could be used as and when
people thought it would be a good idea.
> Or write a shiny new Template::Test for TT version 3 and leave v2 to fester
> in it's own mess :-)
That's going to be written in pbc, right ;-)[1] ?
Mark.
[1] What's the emoticon for "I'm joking, but on the other hand I might not
be"
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t->Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t->Tgoto(cm,$_,$y)." $w";select$k,$k,$k,.03}$y+=2}
