On Sat, Feb 17, 2001 at 03:10:30PM -0500, [EMAIL PROTECTED] wrote:
> Dangerous. Take Test.pm for instance. It expects certain tests to be
> on certain lines because it reads back its own error messages.
>
>
> Ok, two birds with one stone. Define t/TestSetup.pm as:
>
> chdir 't' if -d 't'
I started using Test::Inline, and I have two related comments. (I hope
this is the right place to bring them up.)
1. I don't think that pod2test should do anything more than the minimum
to construct a valid test script. Anything else that is useful
should be part of the standard Test::
On Wed, Jun 09, 2004 at 08:18:30AM -0700, Ovid wrote:
> As for porting a Test::More style framework, I tried doing that with
> Python and was actually doing well with it, but I was shot down pretty
> quickly.
Any specific reasons why (is the discussion archived)? Is there any
site that compares t
When using Test::Inline, it is likely that not all perl files will have
inline tests. However, in a build system, the simplest thing to do is
build test scripts for all of them anyway, and have the test harness be
smart enough to ignore the ones with no tests. There are two small
problems:
1. p
On Fri, Jun 11, 2004 at 02:00:58PM -0500, Andy Lester wrote:
> Seems to me that if T:H is passed a test file, it's not unreasonable for
> it to expect at least one test.
No, not unreasonable. But I think it's also not unreasonable to reserve
empty file to mean "no tests yet, ignore".
> How abo
On Fri, Jun 11, 2004 at 01:26:36PM -0600, Wiggins d Anconia wrote:
> > On Fri, Jun 11, 2004 at 02:00:58PM -0500, Andy Lester wrote:
> > > Seems to me that if T:H is passed a test file, it's not unreasonable for
> > > it to expect at least one test.
> >
> > No, not unreasonable. But I think it's
On Fri, Jun 11, 2004 at 09:36:41PM +0100, Adrian Howard wrote:
> What does an empty test file give you over an absent one?
Cleaner build system. You simply say, for every Perl file, run pod2test
to build a test file, then run all the test files. Something like:
%.pm.t: %.pm
pod2
On Sat, Jun 19, 2004 at 09:11:43PM -0200, Gabor Szabo wrote:
>
> I would like to test a module for unsuccessful "require" while the
> required module is installed. That is I'd like ot test how my code would
> work if Foo.pm was not present.
>
> In the middle of a module I have code such as
>
> e
On Thu, Jun 24, 2004 at 07:09:40AM +0100, Piers Cawley wrote:
> The xUnit style framework does a much better job of enforcing test
> isolation than Test::More does
I see this more as a limitation than a feature. It seems to mean that
- You need to use the same setup/teardown for all your tests.
On Thu, Jun 24, 2004 at 05:08:44PM +0100, Adrian Howard wrote:
> Where xUnit wins for me are in the normal places where OO is useful
> (abstraction, reuse, revealing intention, etc.).
Since you've thought about this, and obviously don't believe "it's OO so
it's better", I'd be interested in seein
On Thu, Jun 24, 2004 at 09:10:09PM +0100, Tony Bowden wrote:
> On Thu, Jun 24, 2004 at 02:59:30PM -0400, Andrew Pimlott wrote:
> > I see this more as a limitation than a feature. It seems to mean that
> > - You need to use the same setup/teardown for all your tests.
>
> Thos
On Fri, Jun 25, 2004 at 07:35:26AM +0100, Tony Bowden wrote:
> On Thu, Jun 24, 2004 at 07:13:08PM -0400, Andrew Pimlott wrote:
> > But (I thought) the idea was that every test needs the same setup. If
> > they're all in one method, they won't get that.
>
> How&#x
On Fri, Jun 25, 2004 at 04:41:15PM +0100, Tony Bowden wrote:
> On Fri, Jun 25, 2004 at 11:10:19AM -0400, Andrew Pimlott wrote:
> > I was responding to your suggestion to put all the tests in one method
> > if they are just parametrized by data. How do you suggest writing the
&g
Ok, now that I understand what library you're using ...
On Fri, Jun 25, 2004 at 04:41:15PM +0100, Tony Bowden wrote:
> On Fri, Jun 25, 2004 at 11:10:19AM -0400, Andrew Pimlott wrote:
> > I was responding to your suggestion to put all the tests in one method
> > if they are
On Wed, Jul 07, 2004 at 02:42:22PM -0400, Michael G Schwern wrote:
> On Fri, Jun 04, 2004 at 10:18:37PM -0400, Andrew Pimlott wrote:
> > I started using Test::Inline, and I have two related comments. (I hope
> > this is the right place to bring them up.)
> >
> > 1.
On Wed, Jul 07, 2004 at 05:46:12PM -0400, Michael G Schwern wrote:
> I think I threw that in before I realized one could just do:
>
> =for testing
> use Test::More 'no_plan';
>
> This was all very early on in my mucking with the Test:: modules. In fact,
> no_plan was implemented specificly so I
On Fri, Jul 09, 2004 at 11:00:28AM -0400, Michael G Schwern wrote:
> wrap *Test::Builder::diag, pre => sub {
> $_[1] = color('red') . $_[1];
> $_[-2] =~ s/$/color 'reset'/e;
> };
Glancing at the Hook::LexWrap, I see it's possible to simulate an
"around" wrapper by calling the original f
I got this error, which I traced down to accidentally calling is() with
a hashref as the third argument, where the name should have been:
use Test::More 'no_plan';
is(1,1,{});
This happens because Test::Builder tries to assign the name to a key of
a shared hash. This simple case demonstr
On Fri, Aug 27, 2004 at 09:24:20AM +0200, Rafael Garcia-Suarez wrote:
> In this case that's a bug in Test::Builder, not in perl.
Sure, but it is a very easy bug to make. For perfectly normal code to
break with threads is scary to me. And the fix looks fragile,
especially without a comment. I wo
On Fri, Aug 27, 2004 at 10:16:48AM +0200, Rafael Garcia-Suarez wrote:
> Andrew Pimlott wrote:
> >
> > Can you tell me where this limitation in perl threads is documented?
> > Is there any hope that it will be removed in the future?
>
> It's not a limitation, if
On Fri, Aug 27, 2004 at 09:20:09AM -0700, chromatic wrote:
> If you don't have an ithreads-capable Perl, T::B won't use threads.
>
> If you do, it must,
Ideally, I would agree. But I think a compromise is in order, because
perl threads aren't that mature and are error-prone to program. And
most
On Fri, Aug 27, 2004 at 12:06:47PM -0700, chromatic wrote:
> It doesn't matter how *you* see Perl threads if users who may run your
> tests see them as worth using
First, as I said, I agree with you "ideally". I understand all the
points you're making, and they're basically valid. But the realit
In certain instances a test file may not know how many test points
it will ultimately be running. In this case the plan can be the last
non-diagnostic line in the output.
This feature is new to me--and I have to say, it seems nearly useless.
I consider that the primary purpose of a pla
On Mon, Feb 21, 2005 at 08:31:43PM -0600, Andy Lester wrote:
> >This feature is new to me--and I have to say, it seems nearly useless.
>
> It's the ages-old argument about the value of the plan. Some people
> don't like the plan, and some do.
I don't mean the plan is new, only the plan at the e
On Mon, Feb 21, 2005 at 08:58:46PM -0600, Andy Lester wrote:
> The plan has to exist, whether it's the first or last line. I've added
> that to the docs.
Ah, that clarifies it. I misunderstood the current situation--I didn't
realize that Test::More automatically adds the plan at the bottom when
On Tue, Apr 05, 2005 at 01:13:53PM +, Mark Stosberg wrote:
> As part of building web applications, I sometimes return a "technical
> failure" page to the web browser when something unexpected happens that
> seems like the software's fault.
>
> I'm wondering if it's the right thing to do to re
On Sat, Jul 02, 2005 at 08:55:34AM +0200, demerphq wrote:
> The entire basis of computer science is based around the idea that if
> you do the same operation to two items that are the same the end
> result is the same.
Citing "computer science" as the basis of your position is just too
much. The
On Sat, Jul 02, 2005 at 07:34:47PM +0100, Fergal Daly wrote:
> On 7/2/05, Andrew Pimlott <[EMAIL PROTECTED]> wrote:
> > Citing "computer science" as the basis of your position is just too
> > much. The "computer science" answer to the comparison of ref
On Sun, Jul 03, 2005 at 01:13:50AM +0100, Fergal Daly wrote:
> On 7/3/05, Andrew Pimlott <[EMAIL PROTECTED]> wrote:
> > Can you give me a hint as to the difference in a language like Perl?
>
> When they are the same reference they are the same reference (can't
> thi
On Sun, Jul 03, 2005 at 12:32:01PM +0100, Fergal Daly wrote:
> On 7/3/05, Andrew Pimlott <[EMAIL PROTECTED]> wrote:
> > How about
> >
> > my $a = [];
> > my $b = [];
> > my $s = sub { $_[0] == $a; }
> > is_deeply($a, $b);
On Sun, Jul 03, 2005 at 01:53:45PM +0200, demerphq wrote:
> On 7/2/05, Andrew Pimlott <[EMAIL PROTECTED]> wrote:
> > On Sat, Jul 02, 2005 at 08:55:34AM +0200, demerphq wrote:
> > > The entire basis of computer science is based around the idea that if
> > > you d
On Mon, Jul 04, 2005 at 12:36:29AM +0200, demerphq wrote:
> On 7/3/05, Andrew Pimlott <[EMAIL PROTECTED]> wrote:
> >Would using
> >
> > my $s = sub { $a->[0] = 1; $_[0]; }
> >
> > above also be "looking at refaddrs"?
>
> No. But
On Tue, Jul 05, 2005 at 01:24:38AM +0100, Fergal Daly wrote:
> There's an easy way to see what's "accptable" and what's not and what
> exactly this level equality means. Consider the following code
> template:
>
> ###
> # lots of stuff doing anything you like including
> # setting global varia
On Tue, Jul 05, 2005 at 10:15:16AM +0200, demerphq wrote:
> (apologies about the slow follow up)
not slow in my book :-)
> On 7/4/05, Andrew Pimlott <[EMAIL PROTECTED]> wrote:
> > On Mon, Jul 04, 2005 at 12:36:29AM +0200, demerphq wrote:
> > > On 7/3/05, Andrew Pimlot
On Wed, Jul 06, 2005 at 12:10:43AM +0100, Fergal Daly wrote:
> On 7/5/05, Andrew Pimlott <[EMAIL PROTECTED]> wrote:
> > my $x = [];
> > sub one_way = { $x }
> > sub another_way = { [] }
> > sub test = { $_[0] == $x }
> >
> > I don't think this b
35 matches
Mail list logo
