Test::Fork (was Re: New Test::More features?)
Eric Wilhelm wrote:
# from Michael G Schwern
# on Thursday 29 November 2007 19:00:
Otherwise, what's important to people?
Could it be made fork-safe?
http://search.cpan.org/src/TJENNESS/File-Temp-0.19/t/fork.t
Possibly that involves blocking, or IPC with delayed output, or a
plan-per-fork thing.
The trick is, how do you do it?
IPC is right out, unportable. I'm pretty sure there's no way to coordinate
the test counter between the two processes. There are TAP proposals to
eliminate the need for coordination but I don't want to get into that right now.
The usual way to do this is to turn off test numbers, fork and then turn them
back on when the fork is done while incrementing the test counter by the
number of tests the fork ran. That requires a bunch of Test::Builder method
level muckery and is non-obvious.
An easier Test::More level interface would be nice, but what would that
interface be? It needs an I'm about to fork for this many tests function
and a I'm done forking function. It would be easier if Test::More did the
forking for you, but that's a restriction I don't want to impose.
Or maybe we just write Test::Fork like so:
use Test::Fork;
fork_ok(sub {
is 23, 42; # this is the code in the fork
});
and it does all the necessary jiggery pokery. Knowing when the fork is
complete to turn numbers back on is troublesome. I guess some sort of signal
handler will deal with that?
PS I note there is Test::MultiFork but it seems to go well beyond what we're
talking about.
--
...they shared one last kiss that left a bitter yet sweet taste in her
mouth--kind of like throwing up after eating a junior mint.
-- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest
by Tami Farmer
Re: New Test::More features?
Andy Armstrong wrote: On 30 Nov 2007, at 03:00, Michael G Schwern wrote: Otherwise, what's important to people? I know there's a lot of suggestions about increasing the flexibility of planning. Also the oft requested I'm done running tests sentinel for a safer no_plan. Most of the time I'm just wibbling over interface details, getting the names just right. (What! Argue over tiny interface issues? The Deuce you say!) The ability to emit TAP 13 c/w structured diagnostics would be hot. Two open, but non-showstopper, issues related to that. 1) What do we do with the regular STDERR diagnostics? Ideally we'd have some way to detect that the harness is going read our YAML diagnostic and generate it's own user-readable version. AFAIK none such thing exists. At the moment, they will just always get emitted. I don't have any other good solution in mind other than accepting an environment variable (tied to a Test::Builder method) to switch it off. It's really a decision the harness has to convey to the tests. 2) What do we do if we don't have a YAML emitter? At the moment, we just won't emit diagnostics. Possibilities include shipping with a copy of YAML::Tiny or write our own dumbed down YAML generator based on the is_deeply() code as it already knows how to walk a data structure. Then we can reopen the debate about the namespace within diagnostic blocks and lose another four weeks of our respective lives :) I'm going to pretend I don't know anything about diagnostic namespaces, which is easy, cause I don't. LALALALALALA -- I have a date with some giant cartoon robots and booze.
[ANNOUNCE] Test::Fork 0.01_01
As threatened, here's Test::Fork for easier writing of forked tests.
http://pobox.com/~schwern/src/Test-Fork-0.01_01.tar.gz
use Test::More tests = 4;
use Test::Fork;
fork_ok(2, sub{
pass(Child);
pass(Child again);
});
pass(Parent);
I'm probably doing the reaping of children wrong. Someone more familiar with
forking might make some suggestions please.
Also, it's not currently checking whether the system is capable of forking.
And I realize I got the number of tests in the synopsis wrong, it should be 4.
Finally, it might be interesting to use an attribute to declare the number of
tests in the fork, like Test::Class.
--
There will be snacks.
Re: TAP::Builder
On 30 Nov 2007, at 07:49, chromatic wrote: I don't believe producer (Test::Builder) and consumer (Test::Harness) are necessarily entirely alike or symmetrical in this regard. T::B pushes and T::H pulls - which makes callbacks or some higher level event driven interface more appropriate for T::H than it would be for T::B. Many extensions to T::H will be observing passing tests or providing UI wrappers. T::B on the other hand is a multiplexer for a variety of inputs. The situation isn't as different as it sounds. There are at least three ways in which people might want to customize prove: What does customize prove look like? Loading modules into the prove tool that alter its behaviour? Writing their own prove-alikes? * the way it causes other things to produce TAP * the way it analyzes parsed TAP * the way it displays the results For some reason I think of event-driven filters. Then again, it is almost midnight local time. Indeed. Which you probably wouldn't consider for Test::Builder. Which was the nub of my gist. T::B allows many talkers and edits the results into a coherent monologue. T::H / prove must allow many listeners to collaborate to produce an interpretation of that monologue. -- Andy Armstrong, Hexten
Re: New Test::More features?
Michael G Schwern wrote: Otherwise, what's important to people? Here's something that's important to me. I'd like to make it easier for people to patch my modules. A bunch of people already have write access to my repository, and I've taken care to ensure that most all the outstanding items are in RT. Ideally what I'd like is a simple way for anyone to say checkout the branch for ticket #19389 (creating it if it doesn't already exist). Then they can work on it and communicate back when they feel its done and ready for review and integration. Ideally each change would be sent back as a comment on the ticket. I'll be trac does this. -- Life is like a sewer - what you get out of it depends on what you put into it. - Tom Lehrer
