New Test::More features?
Looking at the tickets for Test::More I see it's mostly down to wishlist items
and unimportant things.
http://rt.cpan.org/Public/Dist/Display.html?Name=Test-Simple
I can identify only two real important bugs, as far as I'm concerned. The
first has to do with overloading. cmp_ok() doesn't DTRT with overloaded
operators and is_eq() can explode in certain edge cases. I tried fixing this
once and it's pretty tricky.
http://rt.cpan.org/Ticket/Display.html?id=24186
http://rt.cpan.org/Ticket/Display.html?id=20940
The other is a pile of bugs having to do with how Test::Builder detects if the
test died. This should be pretty easy to fix and eliminates the troublesome
$SIG{__DIE__} handler.
http://rt.cpan.org/Ticket/Display.html?id=30081
http://rt.cpan.org/Ticket/Display.html?id=25294
http://rt.cpan.org/Ticket/Display.html?id=12359
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!)
--
Stabbing you in the face so you don't have to.
Re: New Test::More features?
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. Then we can reopen the debate about the namespace within diagnostic blocks and lose another four weeks of our respective lives :) -- Andy Armstrong, Hexten
Re: New Test::More features?
# 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. --Eric -- "...the bourgeoisie were hated from both ends: by the proles, because they had all the money, and by the intelligentsia, because of their tendency to spend it on lawn ornaments." --Neal Stephenson --- http://scratchcomputing.com ---
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.
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
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
