On Mon, Jul 08, 2002 at 12:46:44PM +0100, Mark Fowler wrote:
> Primarily my concern is that Template::Test is not interoperability with any
> other Test suites.
Indeed. Template::Test was hewn from living bytes in the days of yore
when Test::More was but a twinkle in Schwern's eye.
> It really could do with being adapted to use the Test::Builder backend,
Yep.
> My secondary concern is that it doesn't allow you to name tests.
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.
[abw@kickflip ~/tt2] perl t/debug.t
1..17
ok 1 - running test_expect()
ok 2 - template processor is engaged
ok 3 - input read and split into 7 tests
ok 4 - template test 1 processed OK: Hello World\nfoo: [% foo %]\n[% DE...
ok 5 - matched expected
ok 6 - template test 2 processed OK: foo: [% foo %]\n[% DEBUG on -%]\nh...
ok 7 - matched expected
...etc...
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.
> >From what I can see from playing around inside Template::Test it'd be
> really really hard to adapt it to work with Test::Builder unless you bit
> the bullet and used no_plan. Template::Test just assumes it's in control
> of the testing process too much.
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.
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.
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 :-)
So any change to the module should support this automatic plan generation.
> If I was to write a Template::Test2 module, how would people feel about
> this being distributed in the core for use of testing various things?
I'd be happy to distribute it in the core as a replacement for
Template::Test...
> It would place another mandatory dependency on installing the software
...if it wasn't for this.
In fact, this is what has stopped me from doing it before. I'm not
against adding dependencies where they're necessary, but in this case,
it's adding one which is only used for testing, doesn't bring any added
features to TT itself, and doesn't add anything that Template::Test
doesn't already do (although it may well do it better).
> (though Test::Builder is core after 5.7.3.)
In 6 months time (hand-waving guess) this will probably be a non-issue,
given that 5.8.0 should be prevalent, if not de-facto by then (we hope).
But right now, I'm concerned that we would be doubling the list of dependant
modules for no new TT features.
But by all means go ahead and write Template::Test2 which can be used
iff Test::More is already installed.
Or better yet, 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.
Or write a shiny new Template::Test for TT version 3 and leave v2 to fester
in it's own mess :-)
A
