[Pdx-pm] Modern testing in perl
enobacon at gmail.com
Sun Mar 7 00:57:15 PST 2010
# from Chad Granum
# on Saturday 06 March 2010 14:59:
>I also want to reduce boilerplate as much as possible. Test::class
>looks amazing, but the boiler plate is putting me off. It should be as
>simple as declaring a package and test methods, the tools should do
I think a lot of the boilerplate has to do with fitting into the *.t
framework and the "done thing" for `make test`. You can, of course,
subclass Module::Build and make your `./Build test` do whatever you
want (would be nice to have plugins to do this sort of thing so you
don't have to paste your subclass code into multiple distros.) It's
possible that generating some *.t files would be a good transition
mechanism to fit what you're doing into that framework.
>Also test::builder is Great and has opened the doors to the amazing
>testing perl can already accomplish, but aside from producers it's
>hard to extend. And you are bound to tap output with t::b. True tap is
>what you want almost all the time, but when it is not what you want
>their is a serious hindrance.
What happened to Test::Builder 2? Output format is one thing, but IMO
the main hangup in Test::Builder is the ad-hoc nature of "what is a
test" in relation to diagnostics and introspection.
>By making result objects thy contain the result, line number, file,
>diag, and other info, then letting the user output whatever they want
>you provide a better opening for useful tools. Tap is only one
>possible thing to do with results, it also means not relying on t:b to
>find the line number and other context for the result, which is
>proving problematic for me sometimes.
This sounds a lot like what the next generation of TAP is trying to
express. The info is, of course, passing through serialization.
The TAP producers and consumers have room for improvement, but the
decoupling is nice because you can improve one at a time. It's also a
pain if you're trying to innovate because you have to go through TAP
format and try to get what you're doing into the standard, supported in
the tools on the other side, etc.
>If you look at my fork branch you will see the beginnings of my
>parallelism, there will be one main process producing all output.
>Essentially every tester function should produce a result object
>giving the result and some context. These all funnel down to the main
>process where they are sent to output plugins. Subprocesses (forked
>code) only use the subprocess plugin which send result objects the the
That sounds a lot like what the TAP::Harness parallelism does, except
you're working off of in-memory data from the parent? That could give
you a preload/copy-on-write boost, but potentially at the cost of
flexibility and maybe with a bottleneck on formatting output.
"But as to modern architecture, let us drop it and let us take
modernistic out and shoot it at sunrise."
More information about the Pdx-pm-list