perlunit-devel — PerlUnit development mailing list

[Perlunit-devel] DEBUG breaks tests

[Adam S. <ad...@sp...>]

Enabling DEBUG in T::U::Assert breaks the try_examples.t test, because
of the

    print "Calling $assertion\n" if DEBUG;

in T::U::Assert::assert().

I haven't checked the effects of enabling other DEBUGs.

Any ideas what to do about it?

[Perlunit-devel] (no subject)

[Adam S. <ad...@sp...>]

Is lib/Test/Unit/tests/TestAssertionCodeRef.pm dead?  It doesn't
currently seem to be used.  We also seem to be missing tests for
Assertion::Regexp and Assertion::CodeRef; I'll add those to
tests/AssertTest.pm along with new tests for the finished ok()
wrapper.

Re: [Perlunit-devel] the old 'ok' chestnut

[Adam S. <ad...@sp...>]

Weaver, Quinn BGI SF (Qui...@ba...) wrote:
> > Adam Spiers ad...@sp... wrote:
> > It's a kind of multiplexing wrapper around assert() and
> > assert_equals(), so the regex matching should work fine too.  I've
> > already committed to Assert.pm if you want to have a look.  It's not
> > finished yet.
> 
> That reminds me:  Test::Unit should explicitly require 5.005; it uses the
> qr// operator and throws references (as opposed to strings) through die.
> Both features were introduced with 5.005.

Good point, thanks.  I've committed a require 5.005 in Makefile.PL.

RE: [Perlunit-devel] the old 'ok' chestnut

[Weaver, Q. B. S. <Qui...@ba...>]

> Adam Spiers ad...@sp... wrote:
> It's a kind of multiplexing wrapper around assert() and
> assert_equals(), so the regex matching should work fine too.  I've
> already committed to Assert.pm if you want to have a look.  It's not
> finished yet.

That reminds me:  Test::Unit should explicitly require 5.005; it uses the
qr// operator and throws references (as opposed to strings) through die.
Both features were introduced with 5.005.
--Q

[Perlunit-devel] issues with sourceforge

[Adam S. <ad...@sp...>]

http://fsfeurope.org/news/article2001-10-20-01.en.html

I haven't looked at this closely enough to decide whether it should
affect us, but I thought I should bring it up just in case.

Re: [Perlunit-devel] the old 'ok' chestnut

[Adam S. <ad...@sp...>]

Piers Cawley (pdc...@bo...) wrote:
> "Hans Donner" <han...@us...> writes:
> 
> > I think you're at risk that youre co-workers will keep using the
> > ok() tests instead of the $self->assert. I think they better write
> > th ok wrapper themselves, instead of providing it if they want to
> > keep the ok.

Nah, they'll use assert() for new stuff if I tell 'em too, and I don't
see the point of writing the wrapper locally, since the Test.pm API is
well documented.

> Maybe if we provide our own 'ok' wrapper, but have it throw a
> 'DEPRECATED' warning the first time it's called in any program run. 
> 
>     Test::Unit::Assert::ok is deprecated, please consider moving over
>     to using Test::Unit::Assert::assert_equals and friends when
>     writing PerlUnit tests.
> 
> If we just make that happen once per run in a way that can be
> overridden (by the user defining a constant OK_IS_OK or something)
> then we get the message across.

Attribute::Deprecated handles this quite nicely, although it doesn't
seem to allow the user to override.  Worth submitting a patch to the
author, I would have thought.  Overriding via some sugar like

  use deprecated 'ok';

would be pretty cute.

> BTW, why didn't we want 'ok'?

I think the original objection was that test code should distinguish
between the different types of equality.  Your new overloading stuff
solves this very nicely though, I think.

> Note too that if 'ok' is going to be a wrapper round assert_equals then
> it's going to fail in the case 'ok $got, qr/$expected_pattern/'
> because assert_equals doesn't do regex matching (because when all's
> said and done 'matches a regex' is a strange definition of 'equals')

It's a kind of multiplexing wrapper around assert() and
assert_equals(), so the regex matching should work fine too.  I've
already committed to Assert.pm if you want to have a look.  It's not
finished yet.

Re: [Perlunit-devel] commits

[Ian R. <ia...@ez...>]

>>>>> " AS" == Adam Spiers <ad...@sp...> writes:

  AS> Ian Robertson (ia...@ez...) wrote:
 IBR> FWIW, on my box, the shift method seems to be a touch faster if there
 IBR> are one or two arguments (including $self); the @_ method starts to
 IBR> win at three.  However, the difference is in the fraction of a
 IBR> microsecond range, so it's probably not a deciding factor :).

  AS> That's odd, my tests show that the more shifts you use, the slower it
  AS> gets.  Try the attached benchmark.  It may be something to do with a
  AS> difference in Perl versions, of course.  Mine's 5.6.0.

That's the same experience I had - for two arguments or less
(including $self), using shift is faster; after that, @_ is faster.

Running 5.005_03 (and changing cmpthese to timethese for my
(presumably older) version of Benchmark), I get these results:

Benchmark: timing 500000 iterations of two_all, two_none, two_one...
   two_all:  4 wallclock secs ( 2.79 usr +  0.00 sys =  2.79 CPU)
  two_none:  3 wallclock secs ( 2.82 usr +  0.00 sys =  2.82 CPU)
   two_one:  2 wallclock secs ( 3.05 usr +  0.00 sys =  3.05 CPU)
Benchmark: timing 500000 iterations of three_all, three_none, three_one...
 three_all:  2 wallclock secs ( 3.29 usr +  0.00 sys =  3.29 CPU)
three_none:  2 wallclock secs ( 3.03 usr +  0.00 sys =  3.03 CPU)
 three_one:  3 wallclock secs ( 3.38 usr +  0.00 sys =  3.38 CPU)
Benchmark: timing 500000 iterations of four_all, four_none, four_one...
  four_all:  7 wallclock secs ( 6.39 usr +  0.00 sys =  6.39 CPU)
 four_none:  7 wallclock secs ( 6.03 usr +  0.00 sys =  6.03 CPU)
  four_one:  7 wallclock secs ( 6.42 usr +  0.00 sys =  6.42 CPU)
Benchmark: timing 500000 iterations of four_all, four_none, four_one...
  four_all:  6 wallclock secs ( 6.44 usr +  0.00 sys =  6.44 CPU)
 four_none:  7 wallclock secs ( 6.09 usr +  0.00 sys =  6.09 CPU)
  four_one:  7 wallclock secs ( 6.34 usr +  0.01 sys =  6.35 CPU)
Benchmark: timing 500000 iterations of five_all, five_none, five_one...
  five_all:  7 wallclock secs ( 6.84 usr +  0.00 sys =  6.84 CPU)
 five_none:  6 wallclock secs ( 6.19 usr +  0.00 sys =  6.19 CPU)
  five_one:  7 wallclock secs ( 6.50 usr +  0.00 sys =  6.50 CPU)


  - Ian

Re: [Perlunit-devel] commits

[Adam S. <ad...@sp...>]

Piers Cawley (pdc...@bo...) wrote:
> Adam Spiers <ad...@sp...> writes:
> > While we're at it, another quick poll:
> > 
> >   my $self = shift;
> >   my $arg = shift;
> > 
> > or
> > 
> >   my ($self, $arg) = @_;
> > 
> > ?
> > 
> > IIRC some of my cow-orkers here benchmarked it and found that the
> > latter was noticeably faster.
> 
> I prefer the former of the two options. I think it reveals your
> intention better (and makes life easier for the refactoring browser
> I'm working on...). However, my current favourite is:
> 
>     my $self = shift;
>     my($arg1, $arg2, @foo) = @_;

That's my favourite too, since it separates the OO handling from the
argument handling.  Except ...

> (Note the lack of space between my and the opening brace...

I find that the lack of space decreases legibility, and also makes it
look more like a function call than a declaration.  Not much in it
though :-)

> > I've added a coding conventions section to doc/consensus.txt for this
> > stuff.  With the presence of the various branches around, I think it's
> > important that we only edit doc/consensus.txt in HEAD.
> 
> Frankly, I'd like to see PDC_REFACTOR merged ASAP,

Absolutely, I'm all for that too.

> but I think there might be a few more modules to move around, I'm
> really not keen on the Test::Unit::TestFoo style, and, from
> discussions elsewhere, I think it'd be a good idea to move
> Test::Unit itself into Test::Unit::Procedural. There seem to be a
> fair few folks at the moment who think that Test::Unit is the main
> interface to PerlUnit.

Good idea.

Re: [Perlunit-devel] commits

[Adam S. <ad...@sp...>]

Ian Robertson (ia...@ez...) wrote:
> >>>>> "AS" == Adam Spiers <ad...@sp...> writes:
>  AS> While we're at it, another quick poll:
> 
>  AS>   my $self = shift;
>  AS>   my $arg = shift;
> 
>  AS> or
> 
>  AS>   my ($self, $arg) = @_;
> 
>  AS> ?
> 
>  AS> IIRC some of my cow-orkers here benchmarked it and found that the
>  AS> latter was noticeably faster.
> 
> FWIW, on my box, the shift method seems to be a touch faster if there
> are one or two arguments (including $self); the @_ method starts to
> win at three.  However, the difference is in the fraction of a
> microsecond range, so it's probably not a deciding factor :).

That's odd, my tests show that the more shifts you use, the slower it
gets.  Try the attached benchmark.  It may be something to do with a
difference in Perl versions, of course.  Mine's 5.6.0.

Re: [Perlunit-devel] commits

[Adam S. <ad...@sp...>]

Piers Cawley (pdc...@bo...) wrote:
> Adam Spiers <ad...@sp...> writes:
> 
> > OK, I've started to commit.  Before I committed anything on the
> > PDC_REFACTOR branch, I did a cvs tag pre_AS_messing, just in case I
> > foul anything up badly ;-)
> > 
> > See the ChangeLog for details of new stuff.
> > 
> > Time for a quick poll; can we reach a consensus on whitespace policy?
> > (I probably already asked this.)  My vote is for no hard tabs
> > anywhere:
> > 
> >     http://adamspiers.org/computing/why_no_tabs.html
> 
> Personally I don't get on with hard tabs either. Though I had this
> editor set up to do them for a while because that appeared to be our
> 'office consensus', but I was mistaken and we're back to using spaces.

OK, I've added that to consensus.txt.

Re: [Perlunit-devel] New maintainer for Test::Unit namespace sought

[Adam S. <ad...@sp...>]

Piers Cawley (pdc...@bo...) wrote:
> le...@ai... writes:
> > Hi folks,
> > 
> > My interests and work life have diverged from Perl and this project
> > to a degree that I am not able to devote the time needed to this
> > project.
> > 
> > However, I don't want to stand in the way, so:
> > 
> > Whoever of this group wants to maintain Test::Unit and the related
> > PerlUnit files on CPAN, please come forward and say so.
> 
> Christian, I'm really sorry to see you leaving. I'd like to extend
> my thanks (and I'm sure, the thanks of everyone else on the list) for
> starting PerlUnit in the first place and carrying things this far.

Absolutely, thanks for all your great work, and I'm sorry to see you
go too (can totally understand why though; I wouldn't have time to
hack PerlUnit if work didn't require it).

> > My recommendation would be to make Piers Cawley the new maintainer,
> > but I leave the decision to the currently active members of this
> > developer group.

I'd be very happy with Piers as maintainer too.

> Thanks for the vote of confidence. Whilst I'm happy to take the job
> on

Great!

> my current main interest is my Perl Refactoring Engine
> (http://sourceforge.net/projects/preface/ if you want to take a look
> at the current undocumented (but with passing tests) tool that can
> just about do extract_method effectively). Though I intend to continue
> working on PerlUnit (in fact I'm using it far more now than I was, so
> I'm finding things that need fixing more often...) there may be people
> better qualified to take it on.

Going with the dogfood principle and the fact that you've been the
most active developer recently, I think it makes the most sense for
you to take it on.  FWIW, I'll be backing you up as much as possible
over the next few weeks :-)

Re: [Perlunit-devel] New maintainer for Test::Unit namespace sought

[Piers C. <pdc...@bo...>]

le...@ai... writes:

> Hi folks,
> 
> My interests and work life have diverged from Perl and this project
> to a degree that I am not able to devote the time needed to this
> project.
> 
> However, I don't want to stand in the way, so:
> 
> Whoever of this group wants to maintain Test::Unit and the related
> PerlUnit files on CPAN, please come forward and say so.

Christian, I'm really sorry to see you leaving. I'd like to extend
my thanks (and I'm sure, the thanks of everyone else on the list) for
starting PerlUnit in the first place and carrying things this far. I'm
happy working on the code as it stands, but if I were starting this
from scratch as you were I think I'd be paralyzed.

> My recommendation would be to make Piers Cawley the new maintainer,
> but I leave the decision to the currently active members of this
> developer group.

Thanks for the vote of confidence. Whilst I'm happy to take the job
on, my current main interest is my Perl Refactoring Engine
(http://sourceforge.net/projects/preface/ if you want to take a look
at the current undocumented (but with passing tests) tool that can
just about do extract_method effectively). Though I intend to continue
working on PerlUnit (in fact I'm using it far more now than I was, so
I'm finding things that need fixing more often...) there may be people
better qualified to take it on.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

[Perlunit-devel] New maintainer for Test::Unit namespace sought

[<le...@ai...>]

Hi folks,

My interests and work life have diverged from Perl
and this project to a degree that I am not able to 
devote the time needed to this project.

However, I don't want to stand in the way, so:

Whoever of this group wants to maintain Test::Unit
and the related PerlUnit files on CPAN, please come
forward and say so.

My recommendation would be to make Piers Cawley
the new maintainer, but I leave the decision to
the currently active members of this developer group.

Cheers,

Christian

Re: [Perlunit-devel] the old 'ok' chestnut

[Piers C. <pdc...@bo...>]

"Hans Donner" <han...@us...> writes:

> I think you're at risk that youre co-workers will keep using the
> ok() tests instead of the $self->assert. I think they better write
> th ok wrapper themselves, instead of providing it if they want to
> keep the ok.

Maybe if we provide our own 'ok' wrapper, but have it throw a
'DEPRECATED' warning the first time it's called in any program run. 

    Test::Unit::Assert::ok is deprecated, please consider moving over
    to using Test::Unit::Assert::assert_equals and friends when
    writing PerlUnit tests.

If we just make that happen once per run in a way that can be
overridden (by the user defining a constant OK_IS_OK or something)
then we get the message across.

BTW, why didn't we want 'ok'?

Note too that if 'ok' is going to be a wrapper round assert_equals then
it's going to fail in the case 'ok $got, qr/$expected_pattern/'
because assert_equals doesn't do regex matching (because when all's
said and done 'matches a regex' is a strange definition of 'equals')

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: [Perlunit-devel] the old 'ok' chestnut

[Hans D. <han...@us...>]

I think you're at risk that youre co-workers will keep using the ok() tests=
 instead of the $self->assert.
I think they better write th ok wrapper themselves, instead of providing it=
 if they want to keep the ok.
 

*********** REPLY SEPARATOR  ***********

>Bearing in mind that (hopefully) in the future there will be lots of
>porting from Test to Test::Unit going on, it's probably worth making
>the transition as painless as possible.  To that end, I'm adding an
>ok() wrapper to do this to the PDC_REFACTOR branch.  That's not
>unreasonable is it?  I can mention in the pod that it's best only used
>during porting, not for writing tests from scratch.
>



_

  Greetings,
  Hans Donner

Re: [Perlunit-devel] commits

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> Weaver, Quinn BGI SF (Qui...@ba...) wrote:
>> > From: Adam Spiers [mailto:ad...@sp...]
>> 
>> > Time for a quick poll; can we reach a consensus on whitespace policy?
>> 
>> I'm with you.
> 
> Cool :-)
> 
> While we're at it, another quick poll:
> 
>   my $self = shift;
>   my $arg = shift;
> 
> or
> 
>   my ($self, $arg) = @_;
> 
> ?
> 
> IIRC some of my cow-orkers here benchmarked it and found that the
> latter was noticeably faster.

I prefer the former of the two options. I think it reveals your
intention better (and makes life easier for the refactoring browser
I'm working on...). However, my current favourite is:

    my $self = shift;
    my($arg1, $arg2, @foo) = @_;

(Note the lack of space between my and the opening brace...

> I've added a coding conventions section to doc/consensus.txt for this
> stuff.  With the presence of the various branches around, I think it's
> important that we only edit doc/consensus.txt in HEAD.

Frankly, I'd like to see PDC_REFACTOR merged ASAP, but I think there
might be a few more modules to move around, I'm really not keen on the
Test::Unit::TestFoo style, and, from discussions elsewhere, I think
it'd be a good idea to move Test::Unit itself into
Test::Unit::Procedural. There seem to be a fair few folks at the
moment who think that Test::Unit is the main interface to PerlUnit.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

Re: [Perlunit-devel] commits

[Piers C. <pdc...@bo...>]

Adam Spiers <ad...@sp...> writes:

> OK, I've started to commit.  Before I committed anything on the
> PDC_REFACTOR branch, I did a cvs tag pre_AS_messing, just in case I
> foul anything up badly ;-)
> 
> See the ChangeLog for details of new stuff.
> 
> Time for a quick poll; can we reach a consensus on whitespace policy?
> (I probably already asked this.)  My vote is for no hard tabs
> anywhere:
> 
>     http://adamspiers.org/computing/why_no_tabs.html

Personally I don't get on with hard tabs either. Though I had this
editor set up to do them for a while because that appeared to be our
'office consensus', but I was mistaken and we're back to using spaces.


-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

[Perlunit-devel] the old 'ok' chestnut

[Adam S. <ad...@sp...>]

It's the old 'ok' issue again, I'm afraid.

I think I'm correct in saying that Piers' new assert_equals() method
has very neatly solved the previous long-standing objections to
PerlUnit having any kind of ok() routine, since it does careful
checking to see what type of things are being compared.

Maybe I'm being fussy, but once I get PerlUnit set up here at work so
that all my cow-orkers can port their existing tests across from using
Test.pm, I'm dreading having to tell them they're going to have to
change every instance of

  ok($got, $expected);

into

  $self->assert_equals($expected, $got);

(note the reversed order), not to mention

  ok(<EXPR>);

into

  $self->assert(<EXPR>);

and

  ok($foo, qr/foo/);

into

  $self->assert(qr/foo/, $foo);

Bearing in mind that (hopefully) in the future there will be lots of
porting from Test to Test::Unit going on, it's probably worth making
the transition as painless as possible.  To that end, I'm adding an
ok() wrapper to do this to the PDC_REFACTOR branch.  That's not
unreasonable is it?  I can mention in the pod that it's best only used
during porting, not for writing tests from scratch.

Re: [Perlunit-devel] commits

[Ian R. <ia...@ez...>]

>>>>> "AS" == Adam Spiers <ad...@sp...> writes:

 AS> Weaver, Quinn BGI SF (Qui...@ba...) wrote:
 >> > From: Adam Spiers [mailto:ad...@sp...]
 >> 
 >> > Time for a quick poll; can we reach a consensus on whitespace policy?
 >> 
 >> I'm with you.

 AS> Cool :-)

 AS> While we're at it, another quick poll:

 AS>   my $self = shift;
 AS>   my $arg = shift;

 AS> or

 AS>   my ($self, $arg) = @_;

 AS> ?

 AS> IIRC some of my cow-orkers here benchmarked it and found that the
 AS> latter was noticeably faster.

FWIW, on my box, the shift method seems to be a touch faster if there
are one or two arguments (including $self); the @_ method starts to
win at three.  However, the difference is in the fraction of a
microsecond range, so it's probably not a deciding factor :).

  - Ian

Re: [Perlunit-devel] commits

[Adam S. <ad...@sp...>]

Weaver, Quinn BGI SF (Qui...@ba...) wrote:
> > From: Adam Spiers [mailto:ad...@sp...]
> 
> > Time for a quick poll; can we reach a consensus on whitespace policy?
> 
> I'm with you.

Cool :-)

While we're at it, another quick poll:

  my $self = shift;
  my $arg = shift;

or

  my ($self, $arg) = @_;

?

IIRC some of my cow-orkers here benchmarked it and found that the
latter was noticeably faster.

I've added a coding conventions section to doc/consensus.txt for this
stuff.  With the presence of the various branches around, I think it's
important that we only edit doc/consensus.txt in HEAD.

RE: [Perlunit-devel] commits

[Weaver, Q. B. S. <Qui...@ba...>]

> -----Original Message-----
> From: Adam Spiers [mailto:ad...@sp...]
> Sent: Wednesday, November 07, 2001 1:03 PM
> To: PerlUnit development list
> Subject: [Perlunit-devel] commits

> Time for a quick poll; can we reach a consensus on whitespace policy?
> (I probably already asked this.)  My vote is for no hard tabs
> anywhere:
> 
>     http://adamspiers.org/computing/why_no_tabs.html

I'm with you.  As it says on the cited page,

Do the world a favour! Put this in your ~/.emacs: 

  (setq indent-tabs-mode nil)

or this in your ~/.vimrc 

:set expandtab

It's brain-dead easy, and there's no downside.
--Q

[Perlunit-devel] commits

[Adam S. <ad...@sp...>]

OK, I've started to commit.  Before I committed anything on the
PDC_REFACTOR branch, I did a cvs tag pre_AS_messing, just in case I
foul anything up badly ;-)

See the ChangeLog for details of new stuff.

Time for a quick poll; can we reach a consensus on whitespace policy?
(I probably already asked this.)  My vote is for no hard tabs
anywhere:

    http://adamspiers.org/computing/why_no_tabs.html

Re: [Perlunit-devel] assert.pm not 100%

[Adam S. <ad...@sp...>]

Hans Donner (co...@po...) wrote:
> Im in the proces of using PerlUnit for an OO-aaplication.
> While doing so, I encountered a problem with the Assert.pm.
> 
> I think Ive localised it.
> 
> At the  elsif (eval {$assertion->isa( UNIVERSAL )} ) {
> 
> a require Test::Unit::Assrtion::Boolean; is missing.

Thanks Hans, I've committed this to the PDC_REFACTOR branch, which
should eventually get merged back into HEAD.

[Perlunit-devel] Cunning stuff in sunit

[Piers C. <pdc...@bo...>]

It turns out that if you're using the smalltalk implementation of
xUnit and a test fails, you can double click on the failed test and
it'll jump to the test in question and trace through it until it
fails. Which is nice...

Wonder if we can do that in TkTestRunner (which I've been completely
ignoring for now.)

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?

[Perlunit-devel] Released PDC_REFACTOR tarball

[Piers C. <pdc...@bo...>]

You see, I'm busy writing a perl refactoring browser
(http://preface.sourceforge.net/) and the tests for that depend on the
PDC_REFACTOR branch of Test-Unit, so, in order to make people's live
easier, I've put a tarball up on Sourceforge.

-- 
Piers

   "It is a truth universally acknowledged that a language in
    possession of a rich syntax must be in need of a rewrite."
         -- Jane Austen?