Michael G Schwern wrote:
On Tue, Mar 08, 2005 at 10:31:48PM +, Fergal Daly wrote:
No, other way around. When a TB instance needs a TB::Counter it just says
$tb->counter which, normally, returns a singleton but you can alter counter()
so it returns something else.
A singleton is a class that o
> > Would this make it possible to run many test scripts (each with its own
> > plan) within the same perl process? 'Cos that would be nifty.
>
> Yes. Though beyond testing testing libraries I don't know why you'd want to
> do that.
Well, all I was going to do was try to shave a few seconds off
I was playfully suggesting that behind simply as an abstraction of what
Test::Builder and Test::Harness provide. No way would I inflict that on
an end-user!
David
Ofer Nave wrote:
David Golden wrote:
Just to be playful with concepts:
* Test::Answer -- holds the details of a particular test
(pa
David Golden wrote:
Just to be playful with concepts:
* Test::Answer -- holds the details of a particular test
(pass/fail/skip/todo)
* Test::Scoresheet -- holds a collection of Test::Answers
* Test::Booklet -- sets up a default Test::ScoreSheet object to hold
results, creates and maintains new o
chromatic wrote:
On the other hand, it doesn't do anything differently with TAP as
currently defined, and I share Schwern's case of howling fantods at
recommending that people look in Test::Builder's test results list. Out
of process interpreting and reporting feels so much nicer.
An addendum o
On Tue, Mar 08, 2005 at 03:05:16PM -0800, Michael G Schwern wrote:
> > A singleton is a class that only ever has 1 instance in existence. If there
> > can be multiple instances of TB::Counter or TB::Run then by definition
> > neither of them are singletons. Conversely if there is only ever 1 instan
chromatic wrote:
On Tue, 2005-03-08 at 17:31 -0500, David Golden wrote:
Yeah, it would be nice if we had a better way to handle this. Perhaps
changing the idiom to:
$Test->ok( $dressed_up, 'How nice do you look?' ) ||
$Test->reason( 'Refusing to wear a tie and jacket' );
and enc
On Tue, 2005-03-08 at 17:31 -0500, David Golden wrote:
> Let me say it a different way. Right now, Test::Builder and
> Test::Harness (et al.) are tightly coupled. It would be nice to break
> or at least reduce that coupling. Stuff deep in Test::Builder assumes
> that the output is TAP. For
On Tue, Mar 08, 2005 at 05:31:27PM -0500, David Golden wrote:
> It would be nice if there were better symmetry so that something
> like is() could stick its "got X, expected Y" message in "reason" field
> of the details array if it fails.
That's a good idea.
On Tue, Mar 08, 2005 at 10:31:48PM +, Fergal Daly wrote:
> > No, other way around. When a TB instance needs a TB::Counter it just says
> > $tb->counter which, normally, returns a singleton but you can alter
> > counter()
> > so it returns something else.
>
> A singleton is a class that only
On Tue, Mar 08, 2005 at 05:35:28PM -0500, David Golden wrote:
> >This is too simplistic for Various Reasons that chromatic and I are still
> >hashing out.
>
> Care to hash in public?
What do you think this thread is about?
On Tue, Mar 08, 2005 at 05:05:02PM -0500, David Golden wrote:
> doing the what I want before I write it. I think the approach works,
> but all this mucking about in the internals of Test::Builder feels like
> voodoo.
All the vodoo has already been done for Test::Tester.
my @results = run_tests
Michael G Schwern wrote:
On Tue, Mar 08, 2005 at 02:54:46PM -0500, David Golden wrote:
Could we also consider moving away from singletons that are hard-wired
to Test::Builder? By that I mean make Test::Builder a 'factory' that
gives either a default, plain vanilla Test::Builder object or else
On Tue, Mar 08, 2005 at 01:42:49PM -0800, Michael G Schwern wrote:
> On Tue, Mar 08, 2005 at 09:36:24PM +, Fergal Daly wrote:
> > Cool, so actually T::B::Counter and T::B::Run are not singletons and
> > Test::Builder is.
>
> No, other way around. When a TB instance needs a TB::Counter it just
chromatic wrote:
On Tue, 2005-03-08 at 14:54 -0500, David Golden wrote:
Also, in thinking through the reorg of Test::Builder, it would be great
if the notion of "success" or "failure" could be isolated from any
particular form of output. That would mean that someone could use
Test::Builder::
On Tue, Mar 08, 2005 at 05:05:02PM -0500, David Golden wrote:
> The use case I've been pondering is to be able to better control the
> granularity of my tests within a particular scripts. Stuff like
> Test::Class and Test::Block gets closer but not quite to what I would
> like. I'd like to be
On Tue, Mar 08, 2005 at 01:44:13PM -0800, Ofer Nave wrote:
> How is CPAN going to support simultaneous development of perl 5 and 6
> versions of modules?
Last I heard Perl 6 will have a completely separate directory from the Perl 5
stuff allowing them to shed any legacy even at the CPAN layout le
Michael G Schwern wrote:
On Tue, Mar 08, 2005 at 03:39:17PM -0500, Michael Graham wrote:
Something that's been sitting in the Test::Builder repository for a while
now is Test::Builder->create. Finally you can create a second Test::Builder
instance. I haven't done much with it and I think $Leve
On Tue, Mar 08, 2005 at 02:39:53PM -0600, Andy Lester wrote:
> On Tue, Mar 08, 2005 at 12:36:30PM -0800, Michael G Schwern ([EMAIL
> PROTECTED]) wrote:
> > Sorry to contradict, but yes it does. All the test methods return if they
> > passed or failed. That's how the "ok( open FILE, "foo" ) || di
chromatic wrote:
I've been writing notes for Test::Builder for Perl 6, though. It's a
little something like:
How is CPAN going to support simultaneous development of perl 5 and 6
versions of modules?
-ofer
On Tue, Mar 08, 2005 at 03:39:17PM -0500, Michael Graham wrote:
> > Something that's been sitting in the Test::Builder repository for a while
> > now is Test::Builder->create. Finally you can create a second Test::Builder
> > instance. I haven't done much with it and I think $Level is still globa
On Tue, Mar 08, 2005 at 09:36:24PM +, Fergal Daly wrote:
> Cool, so actually T::B::Counter and T::B::Run are not singletons and
> Test::Builder is.
No, other way around. When a TB instance needs a TB::Counter it just says
$tb->counter which, normally, returns a singleton but you can alter co
On Tue, Mar 08, 2005 at 12:50:29PM -0800, chromatic wrote:
> On Tue, 2005-03-08 at 20:40 +, Fergal Daly wrote:
>
> > By singleton do you mean that there's only ever 1 Test::Builder::Counter and
> > it's shared between all the Test::Builder objects?
>
> By default there's only one. You can cr
On Tue, 2005-03-08 at 20:40 +, Fergal Daly wrote:
> By singleton do you mean that there's only ever 1 Test::Builder::Counter and
> it's shared between all the Test::Builder objects?
By default there's only one. You can create others, if necessary.
> One way to allow this is to have a single
By singleton do you mean that there's only ever 1 Test::Builder::Counter and
it's shared between all the Test::Builder objects? That's necessary in order
to maintain consitent numbering of tests but it doesn't allow for a
second counter to be established to temporarily count subtests (for example
w
On Tue, Mar 08, 2005 at 12:36:30PM -0800, Michael G Schwern ([EMAIL PROTECTED])
wrote:
> Sorry to contradict, but yes it does. All the test methods return if they
> passed or failed. That's how the "ok( open FILE, "foo" ) || diag $!"
> idiom works.
Right, but not on the larger scale. The "okne
> Something that's been sitting in the Test::Builder repository for a while
> now is Test::Builder->create. Finally you can create a second Test::Builder
> instance. I haven't done much with it and I think $Level is still global
> across all instances (bug) but I figured folks would want to play
On Tue, Mar 08, 2005 at 02:29:22PM -0600, Andy Lester wrote:
> On Tue, Mar 08, 2005 at 12:21:35PM -0800, Michael G Schwern ([EMAIL
> PROTECTED]) wrote:
> > > Also, in thinking through the reorg of Test::Builder, it would be great
> > > if the notion of "success" or "failure" could be isolated fro
On Tue, Mar 08, 2005 at 12:21:35PM -0800, Michael G Schwern ([EMAIL PROTECTED])
wrote:
> > Also, in thinking through the reorg of Test::Builder, it would be great
> > if the notion of "success" or "failure" could be isolated from any
> > particular form of output. That would mean that someone c
On Tue, Mar 08, 2005 at 02:54:46PM -0500, David Golden wrote:
> Could we also consider moving away from singletons that are hard-wired
> to Test::Builder? By that I mean make Test::Builder a 'factory' that
> gives either a default, plain vanilla Test::Builder object or else a
> specific subclass
On Tue, Mar 08, 2005 at 12:09:02PM -0800, chromatic wrote:
> > > Test::Builder::TestResults - the parent class for all types of tests
> > > (pass, fail, todo, skip). This may be too much detail here, but I like
> > > the idea of these knowing how to format themselves for output.
> >
> > Dunno wha
On Tue, Mar 08, 2005 at 07:59:04PM +, Fergal Daly wrote:
> > Darcs runs on non-Unix. 2>&1 is not cross-platform.
>
> I ported something form linux to win not so long ago and it worked. Googling
> for
>
> "2>&1" windows
>
> turns a few batch files that use it and also
>
> http://mailman.lyr
On Tue, 2005-03-08 at 14:54 -0500, David Golden wrote:
> Could we also consider moving away from singletons that are hard-wired
> to Test::Builder? By that I mean make Test::Builder a 'factory' that
> gives either a default, plain vanilla Test::Builder object or else a
> specific subclass? E.g
On Tue, 2005-03-08 at 11:40 -0800, Michael G Schwern wrote:
> > Test::Builder::TestResults - the parent class for all types of tests
> > (pass, fail, todo, skip). This may be too much detail here, but I like
> > the idea of these knowing how to format themselves for output.
>
> Dunno what this i
On Tue, Mar 08, 2005 at 10:14:01AM -0800, Michael G Schwern wrote:
> On Tue, Mar 08, 2005 at 05:48:28PM +, Fergal Daly wrote:
> > In the case of though darcs though, is Perl just testing the output of
> > commands that have been systemed? If so they could just add 2>&1 to the
> > command line a
Having an instance is great.
Could we also consider moving away from singletons that are hard-wired
to Test::Builder? By that I mean make Test::Builder a 'factory' that
gives either a default, plain vanilla Test::Builder object or else a
specific subclass? E.g.,
use Test::Builder 'Test::Build
On Tue, Mar 08, 2005 at 11:24:59AM -0800, chromatic wrote:
> > chromatic, do you still have those notes?
>
> Hm, not anywhere close. I think they were on your laptop, the one you
> took apart at the last TPC in San Diego.
Then it may be gone as Apple ate my last hard drive. It possible I have
a
On Tue, 2005-03-08 at 10:25 -0800, Michael G Schwern wrote:
> What's still missing is a way to swap out the Test::Builder singleton with
> your own custom subclass instance. There's some complicated issues there
> which chromatic and I talked over a couple years ago and then promptly did
> nothin
As threatened, Shell::Command 0.01 is on its way to CPAN. Meanwhile its
available here:
http://www.pobox.com/~schwern/src/Shell-Command-0.01.tar.gz
and the repo here
http://svn.schwern.org/svn/CPAN/Shell-Command/trunk/
On Tue, Mar 08, 2005 at 05:48:28PM +, Fergal Daly wrote:
>
> In the case of though darcs though, is Perl just testing the output of
> commands that have been systemed? If so they could just add 2>&1 to the
> command line and then ignore stderr,
I thought that wouldn't be portable.
Mark
On 2005-03-08, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 08, 2005 at 05:27:34PM +, Fergal Daly wrote:
>> On Tue, Mar 08, 2005 at 04:56:08PM +, Mark Stosberg wrote:
>> > Hmm...maybe Test::Output just needs a new feature:
>> >
>> > # Because sometimes you don't care who sai
On 2005-03-08, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 08, 2005 at 11:33:30AM -0500, Mark Stosberg wrote:
>> > I'd make life simpler and dump the shell scripts, see the note about
>> > cross-platform compatibility below.
>>
>> The philosophy behind allowing both is to have a low
Something that's been sitting in the Test::Builder repository for a while
now is Test::Builder->create. Finally you can create a second Test::Builder
instance. I haven't done much with it and I think $Level is still global
across all instances (bug) but I figured folks would want to play with it
On Tue, Mar 08, 2005 at 05:48:28PM +, Fergal Daly wrote:
> In the case of though darcs though, is Perl just testing the output of
> commands that have been systemed? If so they could just add 2>&1 to the
> command line and then ignore stderr,
Darcs runs on non-Unix. 2>&1 is not cross-platform
On Tue, Mar 08, 2005 at 09:34:17AM -0800, Michael G Schwern wrote:
> There's no equivalent to this?
>
> my $output = `some_program 2>&1`;
>
> Where STDOUT and STDERR are combined into one stream, keeping the order
> correct.
If there is it's not in the docs. They show things like
output_l
On Tue, Mar 08, 2005 at 05:27:34PM +, Fergal Daly wrote:
> On Tue, Mar 08, 2005 at 04:56:08PM +, Mark Stosberg wrote:
> > Hmm...maybe Test::Output just needs a new feature:
> >
> > # Because sometimes you don't care who said it.
> > stdout_or_stderr_is()
>
> Test::Output allows
>
> my
On Tue, Mar 08, 2005 at 04:56:08PM +, Mark Stosberg wrote:
> Hmm...maybe Test::Output just needs a new feature:
>
> # Because sometimes you don't care who said it.
> stdout_or_stderr_is()
Test::Output allows
my ($stdout, $stderr) = output_from {...};
then you can do your own tests, other
On Tue, Mar 08, 2005 at 11:33:30AM -0500, Mark Stosberg wrote:
> > I'd make life simpler and dump the shell scripts, see the note about
> > cross-platform compatibility below.
>
> The philosophy behind allowing both is to have a low barrier to entry
> for people submitting tests. Better to have te
On 2005-03-08, Michael G Schwern <[EMAIL PROTECTED]> wrote:
>
> PS I took a look at one of the Perl tests (pull.pl) and its needlessly
> Unix-centric making lots of shell calls which can easily be done with
> Perl, particularly rm -rf and mkdir -p (File::Path). Best to make it
> cross-platform as
On Tue, Mar 08, 2005 at 08:23:31AM -0800, Michael G Schwern wrote:
>
> perl -MTest::Harness -e 'runtests @ARGV' tests/*.pl
Aha. Thanks.
> Why would you distribute a private copy of Test::Harness?
To use 'prove', which your example above illustrates I don't need.
> Or do you mean you
On Tue, Mar 08, 2005 at 03:31:37PM +, Mark Stosberg wrote:
> Right now the tests are run one at a time, losing the benefit
> of the summary report.
>
> I got stuck trying to think of how to best make this work.
>
> I don't think I want to use 'Makefile.PL', because the project already
> has
I have a fork of the 'testing non-modules' question. :)
I help maintain some Perl test scripts for darcs [1].
1. http://www.darcs.net/
Right now the tests are run one at a time, losing the benefit
of the summary report.
I got stuck trying to think of how to best make this work.
I don't thin
On Tue, Mar 08, 2005 at 03:25:45PM +, Mark Stosberg ([EMAIL PROTECTED])
wrote:
> Perhaps you mean this:
>
> $mech->get_ok( $url, 'Fetched home page' );
Yes, that's what I meant. My mistake.
xoa
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
On 2005-03-04, Andy Lester <[EMAIL PROTECTED]> wrote:
> I've updated Test::WWW::Mechanize to add get_ok() and follow_link_ok()
> methods. If you've been writing
>
> $mech->get( $url );
> ok( $mech->success, 'Fetched home page' );
>
> you can now do that as
>
> $mech->get_ok( $mech->success,
54 matches
Mail list logo
