Re: Is_deeply and closure-driven coderefs

[demerphq]

On 5/30/06, chromatic <[EMAIL PROTECTED]> wrote:

On Tuesday 30 May 2006 12:08, Nicholas Perez wrote:

> Why not compare signatures? Is that not feasible?

Which signatures?  Is it important that the code comes from the same place
(check the CV properties) or that the code has bound to the same lexicals
(PadWalker) or that the lexicals are in the same state (more PadWalker)?


And as Schwern said, if you are going to do all that stuff you might
as well use DDS to do it, as its much easier, (which is hardly
surprising as the  Padwalker closure code was specifically written for
DDS'es requirements)

Cheers,
Yve

--
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: Is_deeply and closure-driven coderefs

[Andrew Gianni]

Thanks, I'm going to give D::D::S a try, as I think it'll do what I'm
looking for. Since I'm testing a subroutine that returns a data-structure
(that happens to contain code-refs), I really don't care about the return
values of the code-refs because those are tested elsewhere (through testing
the closure subroutines) I just want to make sure that the structures are
identical.

Thanks much for the suggestions!

Andrew


On 5/31/06 4:48 AM, "demerphq" <[EMAIL PROTECTED]> wrote:

> On 5/30/06, chromatic <[EMAIL PROTECTED]> wrote:
>> On Tuesday 30 May 2006 12:08, Nicholas Perez wrote:
>> 
>>> Why not compare signatures? Is that not feasible?
>> 
>> Which signatures?  Is it important that the code comes from the same place
>> (check the CV properties) or that the code has bound to the same lexicals
>> (PadWalker) or that the lexicals are in the same state (more PadWalker)?
> 
> And as Schwern said, if you are going to do all that stuff you might
> as well use DDS to do it, as its much easier, (which is hardly
> surprising as the  Padwalker closure code was specifically written for
> DDS'es requirements)
> 
> Cheers,
> Yve



Andrew Gianni
Administrative Computing Services
Computing and Information Technology
University at Buffalo
215 MFAC, Ellicott Complex
Buffalo, NY 14261-0026
716.645.3587x7124

Running individual unit tests with Test::Class???

[Andrew Gianni]

Let me start by admitting that I don't know a whole lot about xUnit testing.
In fact, using Test::Class is really my first exposure to the idea, so
perhaps I'm asking for something that doesn't make sense; please bear with
me in case I am.

Test::Class seems like a great idea for so many reasons, but the one thing
that seems like it ought to be easy to do, but I can't figure out how to
accomplish, is running one unit test (or set of unit tests) by just running
one test method. For example, say I have a test class with fifteen test
methods, but I really only care about one of them right now, they're atomic
after all. Is there an easy way to just run that one test method (as well as
the startup, setup, teardown and shutdown methods) while I'm working on it
rather than running the whole batch? I can vaguely see how I could do it
manually by writing a script to do it for me, but is there some other,
easier way to do this that's built into the module?

Andrew



Andrew Gianni
Administrative Computing Services
Computing and Information Technology
University at Buffalo
215 MFAC, Ellicott Complex
Buffalo, NY 14261-0026
716.645.3587x7124

Re: Running individual unit tests with Test::Class???

[A. Pagaltzis]

Hi Andrew,

* Andrew Gianni <[EMAIL PROTECTED]> [2006-05-31 15:40]:
> Is there an easy way to just run that one test method (as well
> as the startup, setup, teardown and shutdown methods) while I'm
> working on it rather than running the whole batch?

just write a base test class with all your scaffolding methods
and then put the individual test units in individual subclasses
that inherit from. You can then easily run just the one set of
tests that you are interested in.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Running individual unit tests with Test::Class???

[Adrian Howard]

[apologies to andrew for a dupe - didn't notice it went to perl-qa]

On 31 May 2006, at 14:35, Andrew Gianni wrote:

Let me start by admitting that I don't know a whole lot about xUnit  
testing.

In fact, using Test::Class is really my first exposure to the idea, so
perhaps I'm asking for something that doesn't make sense; please  
bear with

me in case I am.


[excellent description snipped]

In short
* Yes running one test method at a time is a sensible things to do.
* No - there currently isn't a simple way of doing this
* Good news - Ovid has submitted a patch to make it easy
* Bad news - I've been too bone idle to apply it

Hopefully I will become less lazy soon :-) Should be in the next  
release, which is well overdue.


Cheers,

Adrian

Re: Running individual unit tests with Test::Class???

[Andrew Gianni]

Yeah, but it's so convenient to have my test classes reflect the classes of
my application. It makes it so easy to see what's going on when I name my
test methods the same thing as the methods in my application.

Andrew

On 5/31/06 10:47 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:

> Hi Andrew,
> 
> * Andrew Gianni <[EMAIL PROTECTED]> [2006-05-31 15:40]:
>> Is there an easy way to just run that one test method (as well
>> as the startup, setup, teardown and shutdown methods) while I'm
>> working on it rather than running the whole batch?
> 
> just write a base test class with all your scaffolding methods
> and then put the individual test units in individual subclasses
> that inherit from. You can then easily run just the one set of
> tests that you are interested in.
> 
> Regards,



Andrew Gianni
Administrative Computing Services
Computing and Information Technology
University at Buffalo
215 MFAC, Ellicott Complex
Buffalo, NY 14261-0026
716.645.3587x7124

Re: Running individual unit tests with Test::Class???

[Andrew Gianni]

Cool, it's manageable for now and our current testing -- using sometimes
large, monolithic Test::More .t files -- is no more flexible so there's no
loss in the move, but the flexibility will be appreciated when you get
around to it. Thanks for putting Test::Class together Adrian!

Andrew

On 5/31/06 10:55 AM, "Adrian Howard" <[EMAIL PROTECTED]> wrote:

> [apologies to andrew for a dupe - didn't notice it went to perl-qa]
> 
> On 31 May 2006, at 14:35, Andrew Gianni wrote:
> 
>> Let me start by admitting that I don't know a whole lot about xUnit
>> testing.
>> In fact, using Test::Class is really my first exposure to the idea, so
>> perhaps I'm asking for something that doesn't make sense; please
>> bear with
>> me in case I am.
>> 
> [excellent description snipped]
> 
> In short
> * Yes running one test method at a time is a sensible things to do.
> * No - there currently isn't a simple way of doing this
> * Good news - Ovid has submitted a patch to make it easy
> * Bad news - I've been too bone idle to apply it
> 
> Hopefully I will become less lazy soon :-) Should be in the next
> release, which is well overdue.
> 
> Cheers,
> 
> Adrian
> 
> 



Andrew Gianni
Administrative Computing Services
Computing and Information Technology
University at Buffalo
215 MFAC, Ellicott Complex
Buffalo, NY 14261-0026
716.645.3587x7124

skip_all with Test::More?

[Tels]

Moin,

I stumbled over a slight problem with Test::More: skip_all is an import 
feature, but not a subroutine. So you can do either:


use Test::More;
my $tests;
BEGIN { $tests = 2; plan tests => $tests; }

SKIP: {
  skip ( 'reason', $tests) if ...; 
  # tests here
  }



which is ugly (needs $test or copy&paste number of tests, and an extra 
SKIP block), or do some trickery with:


 
Test::More;

if (...)
  {
  Test::More->import( skip_all => 'reason');
  }

Test::More::plan ( 123 );

# tests here



This is a bit better, but fumbly and I am not sure it will always work, 
especially the bit with calling import etc.

Idially I would like to write:



use Test::More;

plan tests => 123;

skip_all( 'reason' ) if ...;

# tests here


Did I miss something or is this simple not yet possible?

Best wishes,

Tels

-- 
 Signed on Wed May 31 17:48:11 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "helft den armen vögeln"  -- gegen kleinschreibung


-- 
 Signed on Wed May 31 17:53:43 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 Firefox: What are you trying to tell me, that I can block pop-ups?
 Morpheus: I'm trying to tell you that when you're ready, you won't have
 to.
   -- Skyshadow (508) on 2004-11-30 at /.



pgpzYVtfxHmC0.pgp
Description: PGP signature

Re: skip_all with Test::More?

[Pete Krawczyk]

Subject: skip_all with Test::More?
From: Tels <[EMAIL PROTECTED]>
Date: Wed, 31 May 2006 17:53:46 +0200

}
}use Test::More;
}
}plan tests => 123;
}
}skip_all( 'reason' ) if ...;
}
}# tests here
}
}
}Did I miss something or is this simple not yet possible?

Actually, it goes something like this:


use Test::More;
plan skip_all, "No tests here" if $some_condition;
plan tests => 22;


skip_all is a plan descriptor and as such needs to be given to plan.

-Pete K
-- 
Pete Krawczyk
  perl at bsod dot net

Re: skip_all with Test::More?

[Geoffrey Young]

Pete Krawczyk wrote:
> Subject: skip_all with Test::More?
> From: Tels <[EMAIL PROTECTED]>
> Date: Wed, 31 May 2006 17:53:46 +0200
> 
> }
> }use Test::More;
> }
> }plan tests => 123;
> }
> }skip_all( 'reason' ) if ...;
> }
> }# tests here
> }
> }
> }Did I miss something or is this simple not yet possible?
> 
> Actually, it goes something like this:
> 
> 
> use Test::More;
> plan skip_all, "No tests here" if $some_condition;
> plan tests => 22;
> 
> 
> skip_all is a plan descriptor and as such needs to be given to plan.

another alternative is to try Test::Plan

  http://search.cpan.org/dist/Test-Plan/

--Geoff