-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 6/26/14, 3:18 PM, Ricardo Signes wrote:
* David Cantrell da...@cantrell.org.uk [2014-06-26T09:19:00]
I understand that Test::Builder::Tester is the way to go these
days - and it's distributed with Test::Builder, so
incompatibilities should
Huzzah!
On 5/1/13 3:38 PM, Paul Johnson wrote:
In accordance with the terms of my grant from TPF this is the monthly
report for my work on improving Devel::Cover covering March 2013.
Sorry for the delay in this report. Most of March and all of April has been a
very busy time for me
On 4/27/13 2:33 PM, Karen Etheridge wrote:
On Sat, Apr 27, 2013 at 10:19:44AM -0400, Ricardo Signes wrote:
Test::Exception fails, which breaks a lot of my basic toolchain from
installing.
Which dists? I'll convert them to Test::Fatal.
No, it's not Test::Exception's fault. They have a
On 4/27/13 3:41 PM, Karen Etheridge wrote:
On Sat, Apr 27, 2013 at 03:22:31PM -0700, Michael G. Schwern wrote:
No, it's not Test::Exception's fault.
No, I understand -- I just prefer Test::Fatal, so I convert dists when
seeing them and I also have a tuit to spare.
Oh, ok then.
0.98_05 is a release candidate for 0.99. I would say this is the last
stable release of Test::More before 1.5.0 but hahahaha I won't say that.
https://metacpan.org/release/MSCHWERN/Test-Simple-0.98_05/
There hasn't been a stable release in two years, so there's likely to be
code which has
On 4/18/13 6:42 AM, Karen Etheridge wrote:
On Wed, Apr 17, 2013 at 11:58:55AM +0200, Philippe Bruhat (BooK) wrote:
I would like to collect your impressions about what worked and what
didn't, what was missing, what you want for next year
For those of us participating remotely, some small
I use a hackathon to...
* Sync up with what else is going on
* Make long standing hard/bikeshed/warnock'd decisions
* Remind myself that there are people behind the emails
* Be a resource for Test::*, TAP, MakeMaker, build...
* Hack away at code, particularly long standing issues which
haven't
On 4/15/13 7:06 PM, Jens Rehsack wrote:
On 15.04.13 18:56, Michael G. Schwern wrote:
TL;DR version...
IMO we only need to clarify what conflicts means and what actions CPAN
tools should take.
We talked in the Consensus Dome about the need for and meaning of the
conflicts relationship
to be patched, note it as a conflict.
We did the work primarily on an EtherPad and in the Test-More Github
issue tracker by a small team of remote and local developers.
Karen Ethridge (ether)
James Mastros (theorbtwo)
Colin Newell
Daniel Perrett (pdl)
Michael G Schwern (schwern)
Nearly
TL;DR version...
IMO we only need to clarify what conflicts means and what actions CPAN
tools should take.
We talked in the Consensus Dome about the need for and meaning of the
conflicts relationship in the CPAN::Meta::Spec.
https://metacpan.org/module/CPAN::Meta::Spec#Prereq-Spec
IIRC the
On 4/15/13 7:02 PM, Mike Doherty wrote:
This requires Moose maintainers to know about all the things their
releases break. Have you considered reversing the directionality so
MooseX::Blah knows about the things which break it? That seems like a
more likely scenario to me, and lets the right
I'd like people's opinions on a possible downgrade of Test::Builder 1.5
in an attempt to make getting a stable release out easier. It has to do
with whether we keep minor changes to the TAP formatting as the new
default or replicate Test::Builder's current quirks.
On 2012.8.15 4:24 AM, Karen Etheridge wrote:
On Sat, Aug 04, 2012 at 04:57:42PM -0700, Michael G Schwern wrote:
Executive Summary: If you're using Test::Builder::Tester to test your Test
module, switch to Test::Tester. It will make the transition to Test::Builder
1.5 smoother and avoid future
Executive Summary: If you're using Test::Builder::Tester to test your Test
module, switch to Test::Tester. It will make the transition to Test::Builder
1.5 smoother and avoid future breakage due to TAP formatting changes.
A lot of the work done fixing CPAN Test::* modules to be compatible with
Executive Summary: I propose Test::Builder 1.5 makes writing tests using fork
as easy as writing tests using threads is. Test::Builder will handle the
coordination for you. Downside: this breaks existing behavior. Rebutal: if
you're testing with fork your tests are probably broken with
Moving along the trail of getting Test::Builder 1.5 ready (and CPAN ready for
Test::Builder 1.5), the next step is to fix the Test modules which are
failing. While they fail, large chunks of CPAN cannot be tested.
I've set up issues for the known failures. Some of them are probably very
easy,
On 2012.7.27 12:48 PM, Jeffrey Thalhammer wrote:
I just discovered that version.pm always treats version numbers with an
underscore as less than the equivalent version number without the underscore.
So 6.63_02 is less than 6.6302. Is it it just me, or does that seem
crazy?
Dealing with
On 2012.7.11 2:39 PM, Daniel Perrett wrote:
I may have missed the point here, but would it be sufficient to have
two flavours of diagnostic calls, distinguishing between pre-test
diagnostics (`forewarn()`) and post-test diagnostics (`reflect()`), or
is the problem that ok() must be a single
On 2012.6.1 5:40 AM, Steffen Schwigon wrote:
I am about to upload Test::TAPv13. I also did an prepan entry for that.
PrePAN: http://prepan.org/module/429En4oFbn .
URL: https://github.com/renormalist/Test-TAPv13
Synopsis:
use Test::TAPv13 ':all'; # must come before Test::More
On 2012.6.24 7:06 AM, Shlomi Fish wrote:
[QUOTE]
t/01basic.t . ok
# Failed test 'error parsing non-existent does_not_exist.xml'
# at t/02parse.t line 238.
# 'Could not create file parser context for file
does_not_exist.xml: No error at
The fifth alpha for Test::Builder 1.5 has been released. It contains work
from Matthew Horsfall, Peter Rabbitson, geistteufel, Karen Etheridge, Michael
Schwern and others.
It primarily addresses threading issues and regressions discovered via testing
CPAN modules.
On 2012.4.14 4:03 AM, Aristotle Pagaltzis wrote:
Which is a bit of a mouthful. Providing a function to get at the
history object would make a bunch of test state introspection easier.
# That looks pretty good.
END { BAIL_OUT() unless test_history-test_was_successful }
I like that.
On 2012.4.11 1:01 PM, Aristotle Pagaltzis wrote:
Unless I'm mistaken, Test::AutoBailOut is doing to need a global
$SIG{__DIE__} handler or override CORE::require or add something to
@INC or try to parse exception messages or something like that. Any
of those have global side effects which can
On 2012.4.10 2:52 PM, Mike Doherty wrote:
On 12-04-10 05:20 PM, Paul Johnson wrote:
On Tue, Apr 10, 2012 at 12:20:20PM -0700, Michael G Schwern wrote:
2. Should use_ok() be discouraged in the documentation?
I'm very much in favour of this.
I don't see any discouragement
On 2012.4.10 6:21 PM, The Sidhekin wrote:
* How would you rewrite a test script such as my own
http://cpansearch.perl.org/src/EBHANSSEN/Test-Trap-v0.2.2/t/00-load.t so
that it does not use use_ok()?
use Test::More tests = 1;
use Test::Trap::Builder::TempFile;
use
On 2012.4.11 7:35 AM, Andy Lester wrote:
So is there ANY legit use for use_ok()?
Yes. Sometimes you want to conditionally test if a module can be loaded and
its import does not blow up.
It's a convenience function so it can be more easily understood what's going
on and we don't each write it a
On 2012.4.11 9:39 AM, Andy Lester wrote:
In this example:
BEGIN {
use_ok( 'App::Ack' );
use_ok( 'App::Ack::Repository' );
use_ok( 'App::Ack::Resource' );
use_ok( 'File::Next' );
}
diag( Testing App::Ack $App::Ack::VERSION, File::Next $File::Next::VERSION,
Perl $], $^X
On 2012.4.11 9:53 AM, Aristotle Pagaltzis wrote:
* Michael G Schwern schw...@pobox.com [2012-04-11 18:35]:
Nope, too much magic for too small a use case.
And faithfully duplicating `use` would be less so? :-)
This discussion is about backing away from that. The most magical bits of
use_ok
On 2012.4.11 11:43 AM, Eirik Berg Hanssen wrote:
If this fails, the test script will terminate immediately:
* I won't get to know if any of the other modules loaded correctly, or how
they fail. Less of the interesting output.
* And there will be no BAIL_OUT, so the rest of the tests will
In a series of patches, Father Chrysostomos and I enhanced use_ok() so that it
can apply lexical effects to more closely emulate the real `use`. For example,
use_ok('strict');
Previously this would just load strict and call import, but strictures would
not actually be applied to your scope.
On 2012.3.14 5:49 PM, James E Keenan wrote:
On a machine where I can only install libraries underneath my home directory,
I today tried to install and use Devel::Cover. After considerable effort, I
was able to install Devel-Cover-0.79. But when I went to use it in
conjunction with 'prove' I
On 2012.2.7 6:29 PM, Jeffrey Thalhammer wrote:
I'm working with a group of Perl developers with various backgrounds and
skill levels.
We have instituted a fairly effective code inspection process, but we still
get
bogged down in debates over what good code is. Unfortunately, the
On 2011.12.6 1:23 AM, Cosimo Streppone wrote:
Plus, what would happen if at some point Mouse wanted to
use TB2 for its test suite?
You might have missed that part of the conversation. TB2 would not depend on
Mouse, it has its own embedded copy. It would work fine.
--
Clutter and overload
On 2011.12.6 10:56 AM, Cosimo Streppone wrote:
I wasn't referring to a dependency problem,
but to the actual code being the same on the
thing-that-tests and thing-that-is-being-tested.
It would be a problem if they were the same code, but they're not because
TB2::Mouse is a copy of an earlier
As a result of the discussions, I'm now reconsidering using Mouse in TB2. Its
interesting, it's not for any of the reasons I thought, but for a distressing
encapsulation breech built into Moose.
The main concern is that the fact that we're using Mouse leaks out. We must
document that we're
You might want to crib from BackPAN::Index. It has a lot of this terminology.
On 2011.12.2 5:21 PM, Jeffrey Thalhammer wrote:
The context is Pinto, which is yet-another suite of libraries and tools
for building a private CPAN-like repository.
Does it explode when hit from the rear? No?
On 2011.11.30 2:04 AM, David Golden wrote:
On Wed, Nov 30, 2011 at 12:39 AM, Michael G Schwern schw...@pobox.com wrote:
There is a 3rd choice, which brings us full circle to where this discussion
started. We write TB2::Object [1] to select load Mouse if its available,
TB2::Mouse otherwise
On 2011.11.30 4:31 AM, David Golden wrote:
On Wed, Nov 30, 2011 at 6:13 AM, Michael G Schwern schw...@pobox.com wrote:
Unfortunately, that would be a circular dependency between Mouse and TB2
unless...
Not a complete dependency, though, as one can function without the
other. As long
On 2011.11.30 7:20 AM, Ricardo Signes wrote:
re: internal use
What does internal define here? What are the boundaries of the space to
which TB2::Mouse use is internal?
Like any other internal use only .pm file in a CPAN module, it can only be
used by the Test-Simple distribution
After the discussion, some pondering and hearing from Goro, I've decided that
TB2::Mouse will be marked for internal use only.
1. People are uncomfortable that I'm shipping a copy of Mouse::Tiny,
let alone making it public.
2. If it's private now, it can be made public later. Can't do it the
On 2011.11.29 9:49 PM, David E. Wheeler wrote:
How much slower will this make running the core tests,
since neither Mouse nor Mouse::XS will every be available
there (during development, at core installation time).
Doing some back of the envelope calculations, it looks like an extra minute
and
On 2011.11.22 8:06 PM, David Golden wrote:
Attributes -- leaving aside types and coercion -- are you just talking
about the sugar?
Mostly, and the sugar is very helpful, but not all of it.
There's also the potential runtime performance win. Mouse XS accessors are
significantly faster than
On 2011.11.23 12:15 AM, Eric Wilhelm wrote:
Was there some work in Moose to generate and load pre-cooked classes for
startup-time basics like the accessors and roles? It seems like being
able to do that work once during `make` would be a big win.
I think that was wrt pre-cooking Moose's
On 2011.11.22 11:22 AM, David Golden wrote:
On Tue, Nov 22, 2011 at 2:02 PM, Eric Wilhelm enoba...@gmail.com wrote:
Is there a way to remove some of the work Mouse is doing at startup?
What is it doing?
How much of Mouse is needed? Could Moo be used? (I ask without
having read the details
On 2011.11.22 11:02 AM, Eric Wilhelm wrote:
By being THE testing framework, it places an upper bound on how fast
anyone's tests can be. 10 .t files per second, no faster. That
sucks.
I agree. But, with XS mouse, you're only cutting the startup time to
0.07s from 0.09s, correct? And
On 2011.11.21 4:07 AM, David Cantrell wrote:
But then how often does one need to 'use Test::More'? Not enough to
bother optimising it, I'd say.
In every single .t file that gets run by just about everybody.
By being THE testing framework, it places an upper bound on how fast anyone's
tests
On 2011.11.21 8:30 AM, David Golden wrote:
My bigger concern would be inclusion of Mouse in core as a dependency,
since the direction of Perl seems to be to have fewer core modules,
not more. I'd run that discussion by p5p/Ricardo before getting too
tied to Mouse.
Mouse won't be in the core.
On 2011.11.17 4:08 AM, Nicholas Clark wrote:
1) It's not really my goal to make it distributable as a CPAN module,
but as just something you copy.
It continues to be my goal to reduce the amount of effort needed to support
the core. Exposing more of the internals runs counter to this.
Test::Builder1.5 is slow. How slow? About 3x slower than 0.98. Enough to
significantly impact test performance. For example, Spiffy takes 1 second
with 0.98 vs 3.3s with 1.5.
I deliberately didn't do any profiling or optimization while the design was
coming together. This avoided spending
Gentlemen, start your smokers!
https://metacpan.org/release/MSCHWERN/Test-Simple-1.005000_001
Thanks very much to the contributors who stepped up:
* James E Keenan
* Jason Galea
* Nóirín Plunkett
* Aaron Crane
* chromatic
* Father Chrysostomos
* Larry Leszczynski
* Michael Ludwig
* Mike Doherty
*
On 2011.11.16 4:19 PM, James E Keenan wrote:
Should we proceed on the assumption that this specifies v12?
http://testanything.org/wiki/index.php/TAP_specification
... and that this specifies v13?
http://testanything.org/wiki/index.php/TAP_version_13_specification
No, not for our
Subtests are now 100% operational in Test::Builder1.5.
It slipped in place very nicely with the new event system, which makes me very
happy, and it's much simpler than it used to be. The only vestige of the old
system I had to retain was tracking TODO tests since that's still done in the
I'd like a smoker setup which can do two things:
1) Run smokes for all the Test:: modules.
2) Compare the results between two different installed versions of Test::More.
This will allow me to smoke Test::Builder 1.5 against CPAN, see what it's
broken and try to fix it.
I've never used the CPAN
On 2011.11.15 1:01 AM, Buddy Burden wrote:
I did not know this ... just to be super-clear, obviously I know that
if I have script.pl and it starts with
#! /usr/bin/perl -w
and I make it executable and run it directly, I get perl -w. But
you're saying that even if I type:
perl
On 2011.11.15 1:14 AM, Buddy Burden wrote:
Okay, just to follow-up in case anyone cared what the resolution on
this one was, changing the loop full of ok()s to one giant pass() or
fail() per loop fixed _everything_. Plus it runs a lot faster now. I
know I've seen test suites that do
On 2011.11.15 6:40 AM, Leon Timmermans wrote:
I'm not seeing the point really. By this logic we can reduce all
frameworks on CPAN to some three letter acronym. To be honest I don't
think Test::Builder is used directly often enough to justify that.
Test::Builder was just one monolithic module.
I have an important task for getting Test::Builder 1.5 stable.
Test::Builder 1.5 outputs TAP version 13. There are minor formatting changes
including a TAP version header and changes to the ending commentary.
A lot of tests look at this output and so they break. Rather than make
everybody
On 2011.11.14 12:41 AM, Philippe Bruhat (BooK) wrote:
I'm more annoyed with the version number being part of the name.
Even if I can understand the reason why (CPAN only knows one way to
upgrade: up).
I used to be with you there.
I've since found it's a remarkably simple and foolproof way to
Having a parallel and featureful testing system is very useful. I use it to
test Test::More (in the Test-Builder1.5 branch). Others might find it useful
to do the same.
t/test.pl is very important to the Perl core tests, but it is largely
undocumented and untested. Going through the p5p
On 2011.11.13 8:39 AM, Reini Urban wrote:
I've come around your hammering lately and had this idea:
Cannot CPAN add logic to avoid downloading your new versions on older
releases?
Yes, but it is non-trivial.
It would requiring creating a new index which supplies modules and versions
for
It's that time again! Time when I hammer the last few nails in the coffin of
a version of Perl.
By which I mean, the next major release of Test::More (aka Test::Builder1.5)
will support 5.8.1 and up. ExtUtils::MakeMaker will probably go that way,
too. This effectively cuts off most of CPAN
On 2011.11.10 7:44 PM, chromatic wrote:
On Thursday, November 10, 2011 at 05:57 PM, Michael G wrote:
If you don't want global warnings, explicitly turn them off with BEGIN { $^W
= 0 }.
I thought the argument that test modules should set global policy unilaterally
died out when I made
On 2011.11.10 7:15 AM, H.Merijn Brand wrote:
Yes, there indeed is a core
(gdb) where
#0 0xc0258c70:0 in free+0x1d0 () from /usr/lib/hpux64/libc.so.1
#1 0x4017f7e0:0 in Perl_safesysfree () at util.c:262
#2 0x400d0ab0:0 in perl_destruct () at perl.c:871
#3
On 2011.11.10 4:59 PM, Buddy Burden wrote:
chromatic/Merjin,
Not use warnings but the -w command line flag -- the non-lexical, warnings-
on-everywhere one.
no change whatsoever. I've now added -w to all #! lines in the t files
Does that do anything? I didn't think prove respected the
On 2011.11.6 5:20 AM, James E Keenan wrote:
You're absolutely correct that it has no docs. Some of this is to avoid
using
the inline POD feature, in case it breaks while developing the core. But it
could be documented either in comments, or POD in an __END__ block, or (the
safest) in a
On 2011.11.5 5:23 AM, James E Keenan wrote:
Does anyone actually use t/test.pl? What does it do? What is it for?
test.pl has the classic meaning of pl meaning Perl Library not the
bastardized Perl Executable. It's a simpler, parallel alternative to
Test::More written using simpler Perl
On 2011.11.3 8:44 PM, Michael G Schwern wrote:
When doing delegation I have a documentation dilemma: do the API docs go in
the delegator or the delegate?
To answer my own question, I've decided to do the best of both worlds.
I will document each object's native methods in it's own .pm file
On 2011.11.2 7:24 PM, James E Keenan wrote:
On 11/2/11 4:35 PM, Michael G Schwern wrote:
Here's all the current gardening tasks.
https://github.com/schwern/test-more/issues?labels=Gardening%2CTest-Builder2sort=createddirection=descstate=openpage=1
I will start to look at these ... but would
When doing delegation I have a documentation dilemma: do the API docs go in
the delegator or the delegate?
In this case it's Test::Builder2::TestCase which delegates to a stack of
Test::Builder2::EventCoordinator objects. The user will primarily interact
with TestCase objects. Only rarely
https://github.com/schwern/test-more/wiki/Subtest-Design
I've decided on a complete design for subtests and written it up, mostly to
get it out of my head before I forget it. :-) Please let me know what you
think. Here's a summary...
In short, from a Test::Builder point of view, subtests do
Designing the subtests made me realize a few things about the event system
that would be better done a little differently. Mostly renaming things.
It would help me immensely if people could do these refactorings so I can
focus on the design. They should be straightforward, it's just time
On 2011.10.30 11:15 PM, Eric Wilhelm wrote:
# from Michael G Schwern
# on Sunday 30 October 2011 20:30:
The current Test::Builder implementation is a mess and its design
cannot go forward. They have to be gotten just right to ensure that
not just nested TAP is supported, but nesting
On 2011.10.30 7:21 PM, David Golden wrote:
I haven't followed the T::B 2 work closely enough, so could I ask you
to please step back and explain the benefits of T::B 1.5 that is worth
stepping backwards in terms of capabilities? What I mean is that we
have TAP::Harness now that processes
On 2011.10.28 12:23 AM, Ovid wrote:
Echo chamber alert: I've often seen long discussions on this list ignore
the real world (though often for good reason). In this case, it sounds
like there's a consideration of removing a feature from TAP.
No, not removing from TAP but removing support for
On 2011.10.28 6:52 AM, David Golden wrote:
Without looking at the actual code, I would guess that the complexity
is implementing subtests while preserving the legacy procedural
interface that wraps calls to a global singleton.
No, that's not really the problem. It was when Ovid originally
On 2011.10.29 3:51 AM, Fergal Daly wrote:
It seems like it's impossible then to declare a global plan in advance
if you use subtests unless you go counting all the sub tests which is
no fun,
Yes, that's a very good point.
use Test::More tests = 3;
subtest first = sub { ... };
tl;dr version: Is it better for event handlers to have one method per type of
event? Or one method to accept all events? Or something else?
Currently event handlers (called EventWatchers) in Test::Builder2 implement
two methods: accept_event and accept_result. accept_result() is a special
On 2011.10.25 12:29 AM, Eric Wilhelm wrote:
I like the sound of plan B, except for the stores itself in combined
with swap me out.
Any specific doubts?
Can the event coordinator keep a stack? At the point where the parent
handler has to tell the coordinator swap me out, you could have
Subtests are the last major feature hurdle for Test::Builder 1.5. They're
kind of a hacky mess in Test::Builder 1 which I don't want to bring forward.
A subtest has to
1) create a separate state of the test
2) change the format of the output
3) communicate the result of the test back to the
tl;dr/Executive Summary
---
Harvest the internal improvements from Test::Builder2 for Test::Builder
creating a backwards compatible Test::Builder 1.5 which accomplishes the
lion's share of the grant deliverables. Have a feature complete alpha release
before the end of
On 2011.7.14 6:00 PM, Eden Cardim wrote:
It appears there are several distributions on CPAN whose tests don't
pass when using several cores. This is an annoyance because some of the
larger deplists nearly always have a module with broken tests in them,
so testing can't just be a
On 2011.4.13 1:50 AM, Jozef Kutej wrote:
citeIt turned out that there is quite a lot that can go wrong./cite
Found this gem in our internal wiki. :-)
My question is regarding the post-install testing. Normally the test are run
before installation and then discarded with all the rest of the
On 2011.3.31 10:00 AM, Michael Ludwig wrote:
Took me a moment to understand that. Would this cover your need?
result_like shift @$results, {
...
};
That's very good! But does it mess with $history's results directly?
Or does $history-result return a shallow copy of the
(moving this to perl-qa because we decided to retire test-users)
On 2011.3.30 6:52 AM, Michael Ludwig wrote:
Michael G Schwern schrieb am 27.01.2011 um 12:09 (+1000):
use Test::More;
use Test::Builder2::Tester;
my $history = capture {
plan tests = 2
https://github.com/schwern/test-more/tree/v2.00_07
The major change since 2.00_06 is diag() and note() are now hooked into the
event system and the formatters. They're log events. See
Test::Builder2::Event::Log for details. This means test failure diagnostics
can now be controlled along with
On 2011.1.31 11:56 AM, brian d foy wrote:
In article 4d4492ac.6080...@pobox.com, Michael G Schwern
schw...@pobox.com wrote:
Do people not care? Is it going over everyone's heads? Is everyone just
waiting for it to be done? Does it not seem like TB2 is relevant?
I want Test::Builder 2
When I started Test::Builder2 I gave it its own mailing list so it could have
its own community and not clutter up perl-qa with detailed chatter about
Test::Builder2 and Test::More development.
I don't get much response to posts on test-more-users, though I know people
are subscribed. perl-qa
https://github.com/schwern/test-more/tree/v2.00_06
Apparently the way you make me write code is send me to a Linux conference.
This is the sixth alpha release of Test::Builder2 and it is a big one. Maybe
not in lines of code, but in concepts.
The major bits are:
The Design Is Working
I'm happy to announce the first rev of Test::Builder2::Tester. It lets you
test Test:: modules without doing string compares on the TAP. You can test a
much wider array of detail and much simpler.
https://github.com/schwern/test-more/blob/Test-Builder2/lib/Test/Builder2/Tester.pm
Here's an
On 2010.10.29 8:36 AM, Pedro Melo wrote:
All the process got me thinking about Test::Builder. I spent a couple
of hours tonight trying to see how would I output JUnit with TB2. I
tried to write a Formatter::JUnit and was mostly successful, but I
could not see how TB2 ties into the current
On 2010.10.16 3:29 PM, Fergal Daly wrote:
I tried to port this import statement to Perl but functions vs methods
makes a general implementation impossible unless you have knowledge of
the module being imported. However there's nothing stopping individual
modules adopting the convention. It's
On 2010.9.28 8:21 AM, Ovid wrote:
There are no standards that I know of because different situations can call
for
different responses. However, be very careful about just mocking everything.
If
you do and their API changes, you'll find yourself with passing tests for
code which
does not
On 2010.5.22 3:45 AM, demerphq wrote:
One thought...
There has been turbulence in the Regexp space over the last versions of perl.
Is it possible these changes might intersect with those changes to
make it harder to compare regexes?
No, not unless this:
$regex1 eq $regex2
and this:
Test::Simple/More/Builder 0.95_02 has just been released. I'm proud to say
that I had very little to do with it. All the commits are the work of Nick
Clayton and him not being afraid to flex his commit bit. :)
http://github.com/schwern/test-more/tree/v0.95_02
0.95_01 introduced fixage [1] (my
I'm planning out my hackathon trip, and I figure it would be silly to fly all
the way to Vienna, hack, and then fly all the way back home without at least
spending a day or two bumming around. Does anyone else have plans to be a
tourist around Vienna or even broader for a day or two after the
Joshua ben Jore wrote:
The just-released EU::MM 6.56 repeats this pattern frequently:
open my($fh), '', ...
or croak(Can't open ... for writing: $!);
...
print $fh ...; # no error checking
close $fh ...; # no error checking
Grepping for code:
egrep -rnH 'print
Joshua ben Jore wrote:
Fortunately there is one key location where MakeMaker does almost all its
writing to disk, ExtUtils::MakeMaker-flush. A simple patch to check that
would be lovely. If you want to write and insert a safe _print() wrapper
method and scatter that around that's fine, too.
Marvin Humphrey wrote:
On Tue, Dec 22, 2009 at 09:03:42PM -0800, Joshua ben Jore wrote:
On Tue, Dec 22, 2009 at 4:29 PM, Michael G Schwern schw...@pobox.com wrote:
A little experimentation with a small disk image shows that close() will
error if there's no disk left. No need to check every
Joshua ben Jore wrote:
On Tue, Dec 22, 2009 at 4:29 PM, Michael G Schwern schw...@pobox.com wrote:
A little experimentation with a small disk image shows that close() will
error if there's no disk left. No need to check every print. And a close()
wrapper is trivial. It does mean there needs
Jim Cromie wrote:
What's notable in its absence is any *real* use of perl-dist's tests.
I dug into the code, and found that this works.
$ HARNESS_TIMER=1 make test
ext/threads/t/end.ok 60 ms
1 - 100 of 1466 matches
Mail list logo
