perlunit-devel — PerlUnit development mailing list

Re: [Perlunit-devel] How to contribute?

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

On Mon, Feb 13, 2012 at 7:13 AM, Greg Banks <gn...@fa...> wrote:
> What's the best way to contribute these ?  Clone the git repo and just start
> hacking?

I'm totally out of touch with this project since I handed over
maintainership, but it looks like Matthew has done a good job of
updating

    http://perlunit.sourceforge.net/

and converting the repository to git (yay!), so if you don't get any
other response, yes - I'd guess the best approach is to fork his
github repo, hack, then send a pull request :-) You could also add the
sourceforge "official" repo as a remote for comparison.

[Perlunit-devel] How to contribute?

[Greg B. <gn...@fa...>]

G'day,

I've been using Test::Unit in a Perl-based test suite for the Cyrus email server.
As part of that I developed some extensions to Test::Unit which

a) allow subsets of the test collection to be specifed easily, in both additive
and subtractive fashion, and

b) allow running tests in parallel (at least on Unix-like systems, it uses fork
and pipe).

You can see these at

http://git.cyrusimap.org/cassandane/tree/Cassandane/Unit/TestPlan.pm

What's the best way to contribute these ?  Clone the git repo and just start
hacking?

-- 
Greg.

[Perlunit-devel] Implementing filter and verbose options for TestRunner

[Desilets, A. <Ala...@nr...>]

Following up on my recent messages, I'm happy to report that I was able to implement both a filter on the test method name, and a verbose mode that prints the name and execution time for each of the test method.

I did this by subclassing TestRunner, and overriding the methods do_run(), start_test() and end_test() so that they do extra stuff before calling the same method of the super class.

- do_run() filters the tests in the test suite before passing it to SUPER::do_run()
- start_test() takes note of the start time and prints the name of the test method before invoking SUPER::start_test()
- end_test() takes note of the end time, calculates the elapsed time, prints it, and forwards to SUPER::end_test()

Alain

[Perlunit-devel] Assertions for strings and nested data structures

[Desilets, A. <Ala...@nr...>]

Well, I have played around a bit with assert_str_equals and assert_deep_equals as implemented in Assert.pm, and I have to say I much prefer my homegrown assert_string_equals and assert_structures_are_equal methods (which I implemented in a subclass TestCaseWithHelpers of TestCase).

Attached are two TestCases which perform the same two assertions, one on a string, and one on a nested data structure, using either the Assert.pm methods or the methods I developed in my TestCaseWithHelpers.

If I run the AssertTest.pm file, the first thing I notice is that it only reports the failure for the test_assert_str_equals() test. In fact, it's even worse than this. If I include this AssertTest in a suite that includes other testcases, the testing process stops as soon as it fails in the AssertTest::test_assert_str_equals() test.

In contrast, if I run the AlainAssert.pm test case, it reports both failures from test_assert_string_equals() and test_assert_structures_are_equal(). Maybe I'm not using Assert.pm properly? I based my code on an example from this pages: http://search.cpan.org/~dexter/Test-Assert-0.03/lib/Test/Assert.pm.

The second thing I notice is that Assert.pm's assert_str_equals() only tells me that the two strings differ, without showing me where they actually differ:

===
.Exception::Assertion: Expected 'To be, or not to be, that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?', got 'To be, or not to be, that is the question:
Whether tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?' at C:\Users\Desiletsa\Documents\eclipse_workspace\WeBiText/UnitTests/AssertTest.pm line 28
===

In contrast, if I run AlainAssert.pm, I get:

===
2) ../../IIPerlUtils/TestingAndDebugging/TestCaseWithHelpers.pm:143 - test_assert_string_equals(AlainAssertTest)

Strings differed. Position of first found difference is shown below.

*** Got string: ***
'To be, or not to be, that is the question:
Whether <*** DIFF FOUND HERE ***>'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?'

*** Expected string: ***
'To be, or not to be, that is the question:
Whether <*** DIFF FOUND HERE ***>tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?'
===

Which immediately tells me that the culprit is the missing single quote in front of "'tis nobler".

The third thing I notice is that if I comment out the test test_assert_str_equals() in AssertTest, so that I can see the failure for the other test test_assert_deep_equal(), I get this:

===
.Exception::Assertion: Nevermind: Structures begin differing at:
  $a->[1]{gender} = 'M'
  $b->[1]{gender} = 'F' at C:\Users\Desiletsa\Documents\eclipse_workspace\WeBiTe
xt/UnitTests/AssertTest.pm line 43
etc..
===

This is pretty good, in that it tells me that there is a problem with the gender of one of the entries in the structures that are being compared. But I have to do a bit of mental work to figure out which of the two male entries it is referring to (namely, the second entry, 'Dave Bloke'). 

In contrast, if I run test AlainAssert, I get:

===
1) ../../IIPerlUtils/TestingAndDebugging/TestCaseWithHelpers.pm:143 - test_assert_structures_are_equal(AlainAssertTest)
Nevermind
The two data structures differed. Below is a diff between the serialization of those data structures.

Strings differed. Position of first found difference is shown below.

*** Got string: ***
':  [ # ARRAY
:  :  { # HASH
:  :  :  first_name => Bloe
:  :  :  gender => M
:  :  :  last_name => Joe
:  :  }
:  :  { # HASH
:  :  :  first_name => Bloke
:  :  :  gender => <*** DIFF FOUND HERE ***>M
:  :  :  last_name => Dave
:  :  }
:  :  { # HASH
:  :  :  first_name => Doe
:  :  :  gender => F
:  :  :  last_name => Jane
:  :  }
:  ]
'

*** Expected string: ***
':  [ # ARRAY
:  :  { # HASH
:  :  :  first_name => Bloe
:  :  :  gender => M
:  :  :  last_name => Joe
:  :  }
:  :  { # HASH
:  :  :  first_name => Bloke
:  :  :  gender => <*** DIFF FOUND HERE ***>F
:  :  :  last_name => Dave
:  :  }
:  :  { # HASH
:  :  :  first_name => Doe
:  :  :  gender => F
:  :  :  last_name => Jane
:  :  }
:  ]
'
===

This output makes it immeediatly clear that the problem is with the gender of Dave Bloke, not Joe Bloe.

Mind you, I can see that in some circumstances, knowing that the problem is with the 2nd entry may be more important than knowing the problem is with Dave Bloke. So I think the best thing would be a mix of the two outputs, namely something like this:

1) ../../IIPerlUtils/TestingAndDebugging/TestCaseWithHelpers.pm:143 - test_assert_structures_are_equal(AlainAssertTest)

The two data structures differed. 
  $a->[1]{gender} = 'M'
  $b->[1]{gender} = 'F'

Below is a diff between the serialization of those data structures.

*** Got string: ***
':  [ # ARRAY
:  :  { # HASH
:  :  :  first_name => Bloe
:  :  :  gender => M
:  :  :  last_name => Joe
:  :  }
:  :  { # HASH
:  :  :  first_name => Bloke
:  :  :  gender => <*** DIFF FOUND HERE ***>M
:  :  :  last_name => Dave
:  :  }
:  :  { # HASH
:  :  :  first_name => Doe
:  :  :  gender => F
:  :  :  last_name => Jane
:  :  }
:  ]
'

*** Expected string: ***
':  [ # ARRAY
:  :  { # HASH
:  :  :  first_name => Bloe
:  :  :  gender => M
:  :  :  last_name => Joe
:  :  }
:  :  { # HASH
:  :  :  first_name => Bloke
:  :  :  gender => <*** DIFF FOUND HERE ***>F
:  :  :  last_name => Dave
:  :  }
:  :  { # HASH
:  :  :  first_name => Doe
:  :  :  gender => F
:  :  :  last_name => Jane
:  :  }
:  ]
'
===

Another thing I dislike about the Assert.pm version is that it prints a long call stack that looks like this, all of which is useless, except the first line. 

===
at C:\Users\Desiletsa\Documents\eclipse_workspace\WeBiText/UnitTests/AssertTest.pm line 43
        $_ = AssertTest::test_assert_deep_equal("AssertTest=HASH(0x357621c)") ca
lled in package Test::Unit::TestCase at C:/Perl/site/lib/Test/Unit/TestCase.pm l
ine 75
        $_ = Test::Unit::TestCase::run_test("AssertTest=HASH(0x357621c)") called
 in package Test::Unit::TestCase at C:/Perl/site/lib/Test/Unit/TestCase.pm line
61
        $_ = Test::Unit::TestCase::__ANON__() called in package Error::subs at C
:/Perl/site/lib/Error.pm line 408
        $_ = eval {...} called in package Error::subs at C:/Perl/site/lib/Error.
pm line 407
        $_ = Error::subs::try("CODE(0x39d63ac)", "HASH(0x39d648c)") called in pa
ckage Test::Unit::TestCase at C:/Perl/site/lib/Test/Unit/TestCase.pm line 66
        $_ = Test::Unit::TestCase::run_bare("AssertTest=HASH(0x357621c)") called
 in package Test::Unit::Result at C:/Perl/site/lib/Test/Unit/Result.pm line 103
        $_ = Test::Unit::Result::__ANON__() called in package Test::Unit::Result
 at C:/Perl/site/lib/Test/Unit/Result.pm line 119
        $_ = Test::Unit::Result::__ANON__() called in package Error::subs at C:/
Perl/site/lib/Error.pm line 415
        $_ = eval {...} called in package Error::subs at C:/Perl/site/lib/Error.
pm line 407
        $_ = Error::subs::try("CODE(0x39d626c)", "HASH(0x39d5e3c)") called in pa
ckage Test::Unit::Result at C:/Perl/site/lib/Test/Unit/Result.pm line 133
        $_ = Test::Unit::Result::run_protected("Test::Unit::Result=HASH(0x39d5f9
c)", "AssertTest=HASH(0x357621c)", "CODE(0x39d5cac)") called in package Test::Un
it::Result at C:/Perl/site/lib/Test/Unit/Result.pm line 107
        $_ = Test::Unit::Result::run("Test::Unit::Result=HASH(0x39d5f9c)", "Asse
rtTest=HASH(0x357621c)") called in package Test::Unit::TestCase at C:/Perl/site/
lib/Test/Unit/TestCase.pm line 51
        $_ = Test::Unit::TestCase::run("AssertTest=HASH(0x357621c)", "Test::Unit
::Result=HASH(0x39d5f9c)", "Test::Unit::TestRunner=HASH(0x2ca16ec)") called in p
ackage Test::Unit::TestSuite at C:/Perl/site/lib/Test/Unit/TestSuite.pm line 278

        $_ = Test::Unit::TestSuite::run("Test::Unit::TestSuite=HASH(0x38d6754)",
 "Test::Unit::Result=HASH(0x39d5f9c)", "Test::Unit::TestRunner=HASH(0x2ca16ec)")
 called in package Test::Unit::TestSuite at C:/Perl/site/lib/Test/Unit/TestSuite
.pm line 278
        $_ = Test::Unit::TestSuite::run("AllTests=HASH(0x38d6484)", "Test::Unit:
:Result=HASH(0x39d5f9c)", "Test::Unit::TestRunner=HASH(0x2ca16ec)") called in pa
ckage Test::Unit::TestRunner at C:/Perl/site/lib/Test/Unit/TestRunner.pm line 54

        $_ = Test::Unit::TestRunner::do_run("Test::Unit::TestRunner=HASH(0x2ca16
ec)", "AllTests=HASH(0x38d6484)", 0) called in package Test::Unit::TestRunner at
 C:/Perl/site/lib/Test/Unit/TestRunner.pm line 183
        $_ = Test::Unit::TestRunner::start("Test::Unit::TestRunner=HASH(0x2ca16e
c)", "AllTests") called in package main at run_tests.pl line 160
        ...propagated in package Error::subs at C:/Perl/site/lib/Error.pm line 4
34.
        ...propagated in package Error::subs at C:/Perl/site/lib/Error.pm line 4
34.
===

So, in conclusion, I will continue using my own homegrown assertions instead of the ones in Assert.pm. 

If people feel that it would make sense for those to be included in the standard version of TestCase.pm, I am more than happy to contribute them to the project, and to look after the integration. Otherwise, I will just post TestCaseWithHelpers somewhere, probably on my personal site:

http://alaindesilets.org/MyPublicSite/tiki-view_blog.php?blogId=1

Cheers,

Alain

Re: [Perlunit-devel] Enhancements to the TestCase class

[Desilets, A. <Ala...@nr...>]

> > Most of those are in the vein of special assertion methods. For
> > example:
> >
> > assert_string_equals($got_string, $exp_string, $message) [...]
> > assert_structures_are_equal($got_struct, $exp_struct, $message) [...]
> 
> It sounds like these are an improvement on the similar assertions
> Perlunit has.  However, similar code came[1] from Test::More and since
> then while Perlunit fixed a few bugs, other test modules gained many
> more useful features[2].

Hum... it would have been nice if the assert_deep_equals() method had been documented in TestCase. It would have avoided me having to reinvent it. I know it's documented as part of the Assert.pm documentation, but I always assumed that this was a class that was internal to PerlUnit, and that I didn't need to know details of it. I never bothered to look there, because all assertions are called from TestCase instances. 

> For these reasons, and the fact we already have enough assert_*
> methods to make a newcomer's head spin, I didn't just pile my methods
> into Test::Unit::Assert .

Looking at the list of assertions on this page:

http://kobesearch.cpan.org/htdocs/Test-Unit/Assert.pm.html

I see that most of what I implemented in TestCaseWithHelpers is indeed already there.

May I respectfully suggest that you put a very prominent link to the documentation of Assert.pm in the documentation for TestCase.pm? Something like a whole section about checking assertions.

> > I would be willing to share those enhancements in the official
> > version of Perl-Unit, if it was deemed appropriate. All those
> > methods are of course unit tested ;-).
> 
> That's great.  If the code isn't already published somewhere we can
> point to (as mine is), I would like to put it in a contrib/ directory
> so people can benefit when they're ready to see about extending the
> framework for themselves.  Does this suit you?  It would mean a small
> code fork, of your class (unless you abandon your copy).

As it turns out, I think pretty much everything I put in TestCaseWithHelpers is a dupliciation of what already exists in Assert.pm. I will start using those instead.

If I find that there are some things in TestCaseWithHelpers that are still of value, then I will post them somewhere and announce it on this list.

> > I am also interested in helping out to implement two improvements
> > that I would like to add to Perl-Unit:
> >
> > - Possibility to filter TestCase or test methods by passing an
> >   argument to the test runner with a string that should the TestCase
> >   class or the test method should match.
> 
> I have a feeling the /^test/ method filter is already configurable.

If it is, it's not clear from any of the documentation I have seen.

> > Also have you looked at t/tlib/RunnerTest.pm ?

I looked at the code briefly, in a first attempt to implement a filter, but didn't get too far. 

It sounds like there are many undocumented features of PerlUnit. Maybe those who know them should publish them in the official documentation?

> I also was thinking recently that some control of the TestSuite would
> be useful.  It is the place to put control of the thorny issue "tests
> run in random order", and maybe also allow parallel execution[3],
> using the "yesterday's weather" model to put the slower tests early.

Actually, I like the "run in random order" part because it forces me to make sure that there are no dependancies between my tests.

It's only recently that I have felt the need for more control over what tests get executed when. This is specifically because some of my recent tests need to create multiple threads. And there are many Perl modules that die when they are being cloned in a new thread. So I have had to split my TestCases into two separate suites, one that is thread-safe, and one that is not. I would not have to do that if I could tell PerlUnit to execute the non-thread safe tests last, in order to avoid cloning a non-thread safe module.

> > - Possibility to ask for a verbose mode where the test runner will
> >   print the name of every test method it runs,
> 
> If you run under Test::Unit::HarnessUnit you get to see each method
> run, although it lacks many useful details like...  the name.

Right... you get to see a dot for each method that gets executed. In most circumstances that's fine, but in some cases, I see a dot that takes forever to execute, and I want to know which test method is taking so long.

> I think also the TkTestRunner give you more interactive information.

Thx, I'll give it a spin.

But in general, I like to run my tests cases through Eclipse, because it's convenient to have everything accessible from my IDE.

> >   as well as the number of seconds that the test took to run.
> 
> Something like this is done by my extension by set_up, tear_down and
> an END block
>   https://github.com/mca-wtsi/perlunit-> extras/blob/707f941d03f929da6e2f0a38d8afff4b3661b84a/testlib/McaTestCase.pm#L575
> 
> because I wanted to know which are those slow tests.  This way has the
> advantage that it doesn't have to obtain a final callback from the
> runner, but it's not pretty.

I don't know how you implemented this, but my TestCaseWithHelpers has some utilities for doing that. Basically, at the start of a test method, you have to invoke start_timing_test($test_method_name), and in the tear_down(), you have to invoke possibly_print_elapsed_time_for_test().

It works, but is clunky, because you have to spell out the name of the test method to start_timing_test(), and if you rename that method, you have to change the name you pass to start_timing_test(). Also, when you want to time a test method, you have to check in the tear_down() method to see if possibly_print_elapsed_time_for_test() is invoked.

I'm sure there is a better way of doing this by modifying TestRunner, but I haven't investigated further.

Alain

Re: [Perlunit-devel] Enhancements to the TestCase class

[Matthew A. <mc...@us...>]

On Fri, Jun 10, 2011 at 03:18:16PM -0400, Desilets, Alain wrote:

> I have been using Perl-Unit happily for some years now, and over the
> years, I have developed a number of useful helper methods in a
> subclass of TestCase called TestCaseWithHelpers.

Hi Alain,

Thanks for mentioning this to me earlier, and I'm sorry I didn't get
back sooner.


Anyway it makes sense to discuss TestCaseWithHelpers on this list.

I guess anyone who uses a tool like this for long makes extensions or
comfortable tweaks.  I did the same, making intermediate base classes
to add some new assertions and setup code.

After partially extracting mine from some only-relevant-to-employer
code, I put it up at
  https://github.com/mca-wtsi/perlunit-extras

but it isn't in a state where I would recommend anything but fishing
in it for ideas.

Thank you for offering yours.


> Most of those are in the vein of special assertion methods. For
> example:
> 
> assert_string_equals($got_string, $exp_string, $message) [...]
> assert_structures_are_equal($got_struct, $exp_struct, $message) [...]

It sounds like these are an improvement on the similar assertions
Perlunit has.  However, similar code came[1] from Test::More and since
then while Perlunit fixed a few bugs, other test modules gained many
more useful features[2].

Perl's testing tools have moved on since Perlunit was cool, and in my
view it would be most constructive to bring the tools closer together
so (ideally) we can all benefit from the combinations of features we
want, without being swamped by complexity and effort to discover them,
and without breaking compatibility.

The intermediate T:U:TestCase class trick is clean and fairly
powerful.  (Perlunit has the problem that it doesn't get the benefit
of subroutine prototypes, since the assertions are method calls, but
that is a problem for another day.)

For these reasons, and the fact we already have enough assert_*
methods to make a newcomer's head spin, I didn't just pile my methods
into Test::Unit::Assert .


> I would be willing to share those enhancements in the official
> version of Perl-Unit, if it was deemed appropriate. All those
> methods are of course unit tested ;-).

That's great.  If the code isn't already published somewhere we can
point to (as mine is), I would like to put it in a contrib/ directory
so people can benefit when they're ready to see about extending the
framework for themselves.  Does this suit you?  It would mean a small
code fork, of your class (unless you abandon your copy).

Also do you have version history for TestCaseWithHelpers which you
would like to import?  I can accept (RCS), CVS, SVN and Git history,
and maybe others.  Once translated to Git I can extract and sanitise
the history to your liking before publishing it.

Or we can just add your current version as one commit.


> I am also interested in helping out to implement two improvements
> that I would like to add to Perl-Unit:
> 
> - Possibility to filter TestCase or test methods by passing an
>   argument to the test runner with a string that should the TestCase
>   class or the test method should match.

I have a feeling the /^test/ method filter is already configurable.
Also have you looked at t/tlib/RunnerTest.pm ?

(Sorry, my knowledge of this codebase has waned.  I just use the bits
I like, and not recently either.)

I also was thinking recently that some control of the TestSuite would
be useful.  It is the place to put control of the thorny issue "tests
run in random order", and maybe also allow parallel execution[3],
using the "yesterday's weather" model to put the slower tests early.


> - Possibility to ask for a verbose mode where the test runner will
>   print the name of every test method it runs,

If you run under Test::Unit::HarnessUnit you get to see each method
run, although it lacks many useful details like...  the name.

I think also the TkTestRunner give you more interactive information.

>   as well as the number of seconds that the test took to run.

Something like this is done by my extension by set_up, tear_down and
an END block
  https://github.com/mca-wtsi/perlunit-extras/blob/707f941d03f929da6e2f0a38d8afff4b3661b84a/testlib/McaTestCase.pm#L575

because I wanted to know which are those slow tests.  This way has the
advantage that it doesn't have to obtain a final callback from the
runner, but it's not pretty.



Overall I would say I currently prefer "extensible, shipped with some
handy extensions" and better support for other Test::* tools, over
having a huge insular API which nobody uses all of.

First I have to get a release accepted.  There are a couple more bugs
in the various trackers, but they don't have failing tests yet.

I also plan to gather feedback and ideas via the SourceForge
"LimeSurvey" hosted app.  I have some questions for the survey, but
please make suggestions too.


Thanks for reading,
-- 
Matthew

[1]
  http://perlunit.git.sourceforge.net/git/gitweb.cgi?p=perlunit/perlunit;a=commit;h=b03cd777c6a8167d2ff50a6239455995ccb84cc8
  http://perlunit.git.sourceforge.net/git/gitweb.cgi?p=perlunit/perlunit;a=commit;h=dca8fab14735649267f72b8904e63cec61aabc83

[2] For example these are neat, and a bit more polished than anything
    I bothered to write for my tests.  I see them as optional extras
for the developer, but wouldn't choose to require them for build.

  http://search.cpan.org/~ovid/Test-Differences-0.61/lib/Test/Differences.pm#DESCRIPTION
  http://search.cpan.org/~sburke/Test-1.25/lib/Test.pm#ENVIRONMENT

[3] I know prove(1) can already do parallelism, at the granularity of
    t/*.t files.  Having the tests run as separate Perl instances
makes this easier, although I guess you pay at each compile time.

[Perlunit-devel] Enhancements to the TestCase class

[Desilets, A. <Ala...@nr...>]

Hi everyone,

I have been using Perl-Unit happily for some years now, and over the years, I have developed a number of useful helper methods in a subclass of TestCase called TestCaseWithHelpers.

Most of those are in the vein of special assertion methods. For example:

assert_string_equals($got_string, $exp_string, $message):
* Compares two strings. If they are not identical, prints the two and shows the location of the first difference found

assert_structures_are_equal($got_struct, $exp_struct, $message):
* Does a deep compare of two data structures, and if they are not the same, prints a human readable serialization of both structures, with the location of the first difference found.
* Structures can be any nested combination of scalars, arrays, hashtables and objects.

I would be willing to share those enhancements in the official version of Perl-Unit, if it was deemed appropriate. All those methods are of course unit tested ;-).

I am also interested in helping out to implement two improvements that I would like to add to Perl-Unit:

- Possibility to filter TestCase or test methods by passing an argument to the test runner with a string that should the TestCase class or the test method should match.
- Possibility to ask for a verbose mode where the test runner will print the name of every test method it runs, as well as the number of seconds that the test took to run.

In order to implement those two improvements though, I might need some help from people who know that code better than I do.

Have a good weekend.

Alain Désilets
Agent de recherche | Research Officer 
Institut de technologie de l'information | Institute for Information Technology Conseil national de recherches du Canada | National Research Council of Canada

[Perlunit-devel] Using Test::Unit on old versions of Perl, Re: Getting up and Running

[Matthew A. <mc...@us...>]

On Mon, Aug 22, 2005 at 05:15:55PM -0400, mah...@va... wrote:

> Thanks for the reply.  As far as the version of PERL I am using here
> is the info: 5.005_03.  Also I am running the current version of
> PerlUnit: v0.24.

Sorry about the long delay.  I went off on holiday and then got sucked
into work when I got back.

Running Test::Unit under this old version of Perl is the cause of the
problem, I think you need 5.6.0 or newer.  I've put on my doc/TODO
that the minimum perl version should be checked because the error
messages you got are really too obscure to know what's going on.


Possible solutions are

 a) upgrade your Perl

I know that some places are stuck to old Perl interpreters for one
reason or another, so although this is the preferred option it isn't
always possible.

 b) use an old version of Perlunit that works with old versions of
 Perl, and deal with the old bugs

Just by memory, I would guess you may need something before version
0.14.  Please let me know if you're going down this road, it may be OK
for a tryout but it's not something I want to force on people.

 c) we could fix the current Perlunit to work with old versions of
 Perl

This will require some work now plus ongoing vigilance against
problems creeping back in at each point.  Looking at POE because it
still supports 5.005_03
  http://search.cpan.org/src/RCAPUTO/POE-0.3202/README

I see the CPAN testers haven't checked this in a while,
  http://testers.cpan.org/show/POE.html

I haven't dipped back into the mail archive to see what was going on
around the time the new keywords were used.  I expect there was some
discussion.

This project is in an unusual position as far as support for old Perl:
if you have some legacy code, it's entirely reasonable to want to
write a test suite to cover it in its native legacy Perl *before*
moving to a new version.


Please let the list know if you're interested in this.

Matthew  #8-)

[Perlunit-devel] Update on maintainership, Re: One-line fix (fwd)

[Matthew A. <mc...@us...>]

On Fri, Dec 17, 2004 at 12:08:52PM +1100, Tim Nelson wrote:

> Can I suggest that we try to get control of the CPAN Test::Unit
> section transferred to someone else here? (Presumably by first
> asking Adam directly, or failing that, talking to CPAN).

Adam got back to me and passed over control of CPAN, but he doesn't
have time to work on the project.

> Looking at the Project Admins for the Sourceforge project, I see:
> 
> 	Still present:
> -	mca-gdl

This is an old username, I now use "mca1001" instead.  Trying to mix
work and non-work didn't work out so well.

> 	Probably *not* present:
> -	adamspiers
> 
> 	Status unknown:
> -	ba22a
> -	cayte
> -	clemburg

Christian's mail is bouncing and his web site said (can't find the
page now) that he's no longer involved.

> -	jefritz
> -	pdcawley

It's possible Piers is around but I've not heard from him recently.

> -	zhon

So for the moment it's just me.  I haven't removed the other people
from the project, it doesn't seem polite and they can remove
themselves if they wish.  Anyone know what other SF projects do?


I have control of most things now, but there is room for more help if
anyone else wants to join.

I'm currently having trouble logging in to rt.cpan.org with my CPAN
credentials so I can't update the bugs there.  No doubt this will get
fixed at some point.


Matthew  #8-)

[Perlunit-devel] Version 0.25 is out

[Matthew A. <mc...@us...>]

[crossposted to both lists, please pick one if you're replying]

Test::Unit 0.25 is released to SourceForge,
  https://sourceforge.net/project/showfiles.php?group_id=2653&package_id=2626&release_id=363716

and CPAN,
  http://search.cpan.org/~mcast/Test-Unit-0.25/

Here's a copy of the SourceForge release notes and change summary,

  Mostly a bugfix release: all outstanding serious bugs are fixed, build
  and install should now be clean (previous version required "force
  install" under cpan shell).

  Updates for new features and minor bugs will follow.


   + significant fixes to assert_deep_equals wrt. circular structures,
     scalar references and comparison of undef; and installation tests
     for these
   + make the is_numeric test stricter, which will affect results from
     assert_equal; tests for is_numeric
   + first stab at a UML class diagram, check the doc/class-diagram.txt
     before relying on it too heavily
   + tidy up and clarify the copyright notices, author POD sections;
     hopefully in a consistent and fair way
   + improve "Show..." dialog in GUI
   + remove some old junk

  Older changes,
   + changes to Test::Unit::Decorator
   + bugfix in T:U::Procedural
   + test and improve filtering

  Please see ChangeLog or CVS logs for more details.


There are still some minor bugs against the package.  I'll work
through these too, but I think the next major work should be on the
documentation.


Matthew  #8-)

Re: [Perlunit-devel] Getting up and Running

[Matthew A. <mc...@us...>]

On Thu, Aug 18, 2005 at 03:17:34PM -0400, mah...@va... wrote:

> I am new to the world of XUnit testing and PerlUnit for that manner.

Hello, welcome to a corner of automated-testing-world.

> [...] I run into issues with the 'make test' [...]


> Subroutine make_new_from_error redefined at blib/lib/Test/Unit/Error.pm 
> line 8.

This is odd, because that should be defined exactly once, in its own
package, in the usual way.  A possible cause for this would be %INC
being cleared or otherwise meddled with.  I don't think any Perlunit
code does this, but I've not checked.


Now to the scary stuff.

> Use of reserved word "our" is deprecated at blib/lib/Test/Unit/Assert.pm 
> line 222.

I suspect this is a warning, not an error.  Doing things which are
merely deprecated should not cause a failure.

>         Bareword "our" not allowed while "strict subs" in use at 
> blib/lib/Test/Unit/Assert.pm line 222.
>         Unquoted string "our" may clash with future reserved word at 
> blib/lib/Test/Unit/Assert.pm line 222.

...but it doesn't know the meaning of "our" and we have an error.

If "our" is a word reserved for future use, this suggests you have a
Perl that predates use of "our" to declare global variables.  My Perl
history is a bit fuzzy, but I think that would place it pre-5.005?
But the Makefile.pl requires 5.005 to start, and you say the Perl may
be too new...

Is it possible that you're missing the part of Perl which defines
"our"?  I don't know whether it's defined but I guess 30 minutes
poking about the source would find it.

>         Array found where operator expected at 
> blib/lib/Test/Unit/Assert.pm line 222, at end of line
>                 (Do you need to predeclare our?)
> Global symbol "@Data_Stack" requires explicit package name at 
> blib/lib/Test/Unit/Assert.pm line 222.
>         syntax error at blib/lib/Test/Unit/Assert.pm line 222, near "our 
> @Data_Stack"

This is fallout from interpreting "our" as a string/bareword.


> The first and third error I am not familiar with at all, but with
> the second error I am thinking that perhaps my version of Perl is
> too new. Any help would be appreciated.  Thanks.

If you could tell me the version of Perl you're using ("perl -v" and
"perl -V", note lower- and uppercase "-v"s) it would really help.

It would also be useful to know whether you're running the v0.24
(current release version) or the current CVS head version.

If this is doesn't turn out to be something simple to resolve (is
there a backwards compatibility mode for this new Perl?) then things
will go faster if I can get hold of the same version that you're
using.  Can you tell me where you got it, please?


Matthew  #8-)

[Perlunit-devel] Getting up and Running

[<mah...@va...>]

Hello All,

I am new to the world of XUnit testing and PerlUnit for that manner.  I 
have gotten all my prerequisite packages installed, I am able to do a 
'make', but I run into issues with the 'make test'.  Here are some of the 
errors I receive that prevent me from doing a successful 'make test':

Subroutine make_new_from_error redefined at blib/lib/Test/Unit/Error.pm 
line 8.
Use of reserved word "our" is deprecated at blib/lib/Test/Unit/Assert.pm 
line 222.
        Bareword "our" not allowed while "strict subs" in use at 
blib/lib/Test/Unit/Assert.pm line 222.
        Unquoted string "our" may clash with future reserved word at 
blib/lib/Test/Unit/Assert.pm line 222.
        Array found where operator expected at 
blib/lib/Test/Unit/Assert.pm line 222, at end of line
                (Do you need to predeclare our?)
Global symbol "@Data_Stack" requires explicit package name at 
blib/lib/Test/Unit/Assert.pm line 222.
        syntax error at blib/lib/Test/Unit/Assert.pm line 222, near "our 
@Data_Stack"

The first and third error I am not familiar with at all, but with the 
second error I am thinking that perhaps my version of Perl is too new. Any 
help would be appreciated.  Thanks.

[Perlunit-devel] Greetings...

[Robert K. <rku...@ob...>]

Sorry for posting to both lists, but I did not know if either was still 
active or not...

So, question 1.  Anyone out there...?

Question 2.  I played a bit with Test::Unit awhile ago and quite liked 
it.  I thought I read once there is/might be integration of  Test::Unit 
with Test::More or Test::Harness?

The reason I ask both questions is because like many (some?) I am 
feeling the need to add automated testing to my good development habits 
so I am doing some test module shopping.  I like the way Test::Unit 
worked but Test::More and Test::Harness seem to be the "standard" way in 
the Perl community. 

Thus I am torn.  If Test::Unit has been abandoned then that may answer 
my question for me.  On the other hand, if maintenance/advancement 
continues and Test::Unit test scripts can easily be incorporated with 
Test::Harness, etc. then I would much rather be liking that...

Robert Kuropkat

Re: [Perlunit-devel] Re: One-line fix

[Andrew A. <aa...@ma...>]

>> 908422  Test::Unit make test fails on try_examples  2004-03-03 04:04

MA> This is a separate problem to the one that's fixed.  It's still broken
MA> in CVS.

MA> It comes down to the order of execution of the tests in
MA> examples/fail_example.pm , or possibly something else similarly
MA> unreliable.  I'll have a look Soon; just changing the ".F." to "..F"
MA> isn't a good solution.

There are two bug-tracking systems for Test::Unit now, one on sf.net and
another one on CPAN. I've posted patch for this on rt.cpan.org
(http://rt.cpan.org/NoAuth/Bug.html?id=2244), take a look, please.

I also would like to bring another issue to your notice
(http://rt.cpan.org/NoAuth/Bug.html?id=6758). Constructing debug messages in
Test::Unit::Assertion::CodeRef makes test run much longer (two times longer
for my small suite (125 tests): from ~10 to ~20 sec).

aa29

Re: [Perlunit-devel] Re: One-line fix

[Tim N. <tim...@we...>]

On Mon, 27 Sep 2004, Matthew Astley wrote:

> On Mon, Sep 27, 2004 at 11:25:04AM +1000, Tim Nelson wrote:
>
>> The two problems below are a bug (the newer one), and a fix to the
>> bug (the older one).  This bug has been fixed in CVS (2 years ago),
>
> That's handy.
>
> Thanks for pointing it out, I've updated the older bug.
>
>> but not on CPAN, and it's blocking any kind of automatic build.  How
>> do we get it fixed on CPAN?
>
> I believe Adam has the details for this.  Adam, are you around?
> Anyone else?
>
>> 908422  Test::Unit make test fails on try_examples  2004-03-03 04:04
>
> This is a separate problem to the one that's fixed.  It's still broken
> in CVS.

 	Yeah, I noticed after I had another look.

> It comes down to the order of execution of the tests in
> examples/fail_example.pm , or possibly something else similarly
> unreliable.  I'll have a look Soon; just changing the ".F." to "..F"
> isn't a good solution.

 	Where do I read about why it isn't a good solution?

 	:)

-- 
Tim Nelson
Server Administrator
WebAlive Technologies Global
Level 1 Innovation Building, Digital Harbour
1010 LaTrobe Street
Docklands, Melbourne, 
Vic, 3008
Phone: +61 3 9934 0812
Fax: +61 3 9934 0899
E-mail: tim...@we...
http://www.webalive.biz/

[Perlunit-devel] Re: One-line fix

[Matthew A. <mc...@us...>]

On Mon, Sep 27, 2004 at 11:25:04AM +1000, Tim Nelson wrote:

> The two problems below are a bug (the newer one), and a fix to the
> bug (the older one).  This bug has been fixed in CVS (2 years ago),

That's handy.

Thanks for pointing it out, I've updated the older bug.

> but not on CPAN, and it's blocking any kind of automatic build.  How
> do we get it fixed on CPAN?

I believe Adam has the details for this.  Adam, are you around?
Anyone else?

> 908422  Test::Unit make test fails on try_examples  2004-03-03 04:04

This is a separate problem to the one that's fixed.  It's still broken
in CVS.

It comes down to the order of execution of the tests in
examples/fail_example.pm , or possibly something else similarly
unreliable.  I'll have a look Soon; just changing the ".F." to "..F"
isn't a good solution.


Matthew  #8-)
-- 
ps. anyone considered registering the domain "sourceforget.ne"?

[Perlunit-devel] One-line fix

[Tim N. <tim...@we...>]

 	The two problems below are a bug (the newer one), and a fix to the bug 
(the older one).  This bug has been fixed in CVS (2 years ago), but not on 
CPAN, and it's blocking any kind of automatic build.  How do we get it 
fixed on CPAN?

 	Thanks,

908422	Test::Unit make test fails on try_examples		2004-03-03 04:04
760491	Procedural create_suite() uses set_up for tear_down	2003-06-25 23:36

 	:)

-- 
Tim Nelson
Server Administrator
WebAlive Technologies Global
Level 1 Innovation Building, Digital Harbour
1010 LaTrobe Street
Docklands, Melbourne, Vic, 3008
Phone: +61 3 9934 0812
Fax: +61 3 9934 0899
E-mail: tim...@we...
http://www.webalive.biz/

Re: [Perlunit-devel] XML Generating Test Runner

[Andrew E. <an...@an...>]

Matthew Astley wrote:

> ...and if the dependencies aren't met, it's not the end of the world?
> 
> I guess the selftests would fail, and this can be inconvenient for
> installers (bug has been filed by Dave for t/try_examples.t).

We can just check for the presence of the XML releated modules, and skip 
the tests if they're not installed.

> I suspect CPAN packages don't support recommended dependencies, but I
> haven't looked into that.

No, I don't think it does either. But we could just not list the XML 
modules as dependencies, then die with something like "Install 
XML::Generator to use Test::Unit::Runner::XML" if the module's used with 
XML::Generator being installed.

>>It depends on Time::HiRes, 
> I'm now quite fond of using this when it's available and falling back
> on plain time() when it isn't, but it depends what you're up to.

I think it's worth leaving this dependency in, since Time::HiRes is such 
a frequently used module. Falling back to time() probably won't help 
much, since it's rare for a single unit test to run for more than a 
second. The elapsed time for each test would just be 0.

> - talk about it (if people turn up for talking)
> - commit it (nice and easy)
> - put the tests somewhere they won't break an install (probably a few
>   hours hacking about)
> - fix enough outstanding bugs to quiet the clamour of the users (!)
>   (probably more talking required)
> - make a release...  requires Piers' cooperation?

Sounds like a plan to me.

> Andrew, are you keen to see your code release ASAP or is it just a
> "make it available and people might find it handy" distribution?

I've got no reason to have the code released ASAP, I think it would be 
better to try to work it in to a proper release of Test::Unit itself. 
The tarball I linked to is purely for any interested readers of the list 
to look at.

If you're happy with the handling of dependencies described above, I'll 
implement it.

   -- Andrew (http://www.andreweland.org)

Re: [Perlunit-devel] XML Generating Test Runner

[Matthew A. <mc...@us...>]

On Tue, Aug 24, 2004 at 11:27:04AM +0100, Andrew Eland wrote:
> Matthew Astley wrote:

> >I was hoping damagecontrol might be something similar in Perl, but 
> >it's Java too.

Sorry, I don't know what made me think that.  Maybe something about
the look+feel?  But the install docs are at
http://damagecontrol.codehaus.org/Installing and they do mention Ruby
explicitly.

> damagecontrol positions itself as a cross language continuous
> integration platform, and it's actually written in Ruby. [...]

The install procedure sounds simple enough.  /me wonders whether Ruby
is installed at work...


> The runner's just a single module.

...and if the dependencies aren't met, it's not the end of the world?

I guess the selftests would fail, and this can be inconvenient for
installers (bug has been filed by Dave for t/try_examples.t).

I suspect CPAN packages don't support recommended dependencies, but I
haven't looked into that.

> It depends on Time::HiRes, 

I'm now quite fond of using this when it's available and falling back
on plain time() when it isn't, but it depends what you're up to.

> XML::Generator, and XML::XPath for the tests. XML::XPath's quite
> heavyweight, but I guess most people using Test::Unit will have it
> installed anyway.

Exactly.

> I'm happy for it to be part of Test::Unit proper, it seems the
> easiest way to go, if you don't mind the extra dependencies that is.
> 
> If anybody wants to look, you can grab the code from:
> http://www.andreweland.org/Test-Unit-Runner-Xml-0.1.tar.gz

Being part of: the "under the same terms as Perl itself" should be
sufficient.

I've unpacked it, will try to grab a roundtuit this weekend.


Apart from the trying it out, other things to do would be

- talk about it (if people turn up for talking)
- commit it (nice and easy)
- put the tests somewhere they won't break an install (probably a few
  hours hacking about)
- fix enough outstanding bugs to quiet the clamour of the users (!)
  (probably more talking required)
- make a release...  requires Piers' cooperation?


Andrew, are you keen to see your code release ASAP or is it just a
"make it available and people might find it handy" distribution?


Matthew  #8-)

Re: [Perlunit-devel] XML Generating Test Runner

[Andrew E. <an...@an...>]

Matthew Astley wrote:

Hi Matthew,

> I was hoping damagecontrol might be something similar in Perl, but 
 > it's Java too.
> The obvious searches on perlmonks.org, cpan.org and Google don't turn
> up any Perl continuous integration programs - anyone know of one?  I
> know the Java ones can kick off a set of Perl tests, but which Perl
> CGI user wants to set up Tomcat?  8-/

damagecontrol positions itself as a cross language continuous 
integration platform, and it's actually written in Ruby. It simply 
checks a module out of CVS (or Subversion), and then runs an arbitary 
command in checked out copy, so it's very easy to set it up for a Perl 
project. It's not very mature yet, but certainly usable.

> It might turn out to be less effort overall, and more useful in terms
> of getting your code distributed
> (e.g. http://packages.debian.org/libtest-unit-perl ), if you add your
> runner to the perlunit project itself.  Would you want to do this?
> What are the dependencies?  Is it just the one class or are there a
> lot of support files to help with the integration side?

The runner's just a single module. It depends on Time::HiRes, 
XML::Generator, and XML::XPath for the tests. XML::XPath's quite 
heavyweight, but I guess most people using Test::Unit will have it 
installed anyway. I'm happy for it to be part of Test::Unit proper, it 
seems the easiest way to go, if you don't mind the extra dependencies 
that is.

If anybody wants to look, you can grab the code from:
http://www.andreweland.org/Test-Unit-Runner-Xml-0.1.tar.gz

   -- Andrew (http://www.andreweland.org)

Re: [Perlunit-devel] XML Generating Test Runner

[Matthew A. <mc...@us...>]

(While I'm posting - sorry I've been quiet for so long.  I'm writing
tested perl again now, and the mca-gdl username is something of a
misnomer 'cos I work somewhere else now.)

On Mon, Aug 23, 2004 at 02:57:19PM +0100, Andrew Eland wrote:

> I've written a Test::Unit::Runner subclass that writes XML reports in
> the format used by JUnit, to allow Test::Unit to work with continuous
> integration systems such as CruiseControl[1] and damagecontrol[2].

That's a neat trick.  I've used CruiseControl a little.  I was hoping
damagecontrol might be something similar in Perl, but it's Java too.

The obvious searches on perlmonks.org, cpan.org and Google don't turn
up any Perl continuous integration programs - anyone know of one?  I
know the Java ones can kick off a set of Perl tests, but which Perl
CGI user wants to set up Tomcat?  8-/

But I digress.

> Does anybody have any issues with me uploading it to CPAN under the
> Test::Unit namespace as Test::Unit::Runner::XML?

I don't know what the arrangements are for "ownership" of namespace.
My guess is that we manage it the way we share seats on trains.

An independent upload to CPAN must be a reasonable thing to do if the
perlunit project can't accommodate you in more useful way.

It might turn out to be less effort overall, and more useful in terms
of getting your code distributed
(e.g. http://packages.debian.org/libtest-unit-perl ), if you add your
runner to the perlunit project itself.  Would you want to do this?
What are the dependencies?  Is it just the one class or are there a
lot of support files to help with the integration side?


I've piped up quick so you don't get the full silence treatment.  I
don't know whether Adam or Piers are still around?  This list has been
quiet for a while, but I would still consider them to be in the
driving seat.

Thanks for dropping in,


Matthew  #8-)

[Perlunit-devel] XML Generating Test Runner

[Andrew E. <an...@an...>]

Hi All,

I've written a Test::Unit::Runner subclass that writes XML reports in
the format used by JUnit, to allow Test::Unit to work with continuous
integration systems such as CruiseControl[1] and damagecontrol[2].
Does anybody have any issues with me uploading it to CPAN under the
Test::Unit namespace as Test::Unit::Runner::XML?

Thanks,

[1] http://cruisecontrol.sourceforge.net/
[2] http://damagecontrol.codehaus.org/

  -- Andrew Eland (http://www.andreweland.org)

[Perlunit-devel] Self-testing Perl-Unit file?

[Phlip <pl...@sy...>]

Perlies:

I want to write a .pl file like this:

sub Subject {
        # blah blah blah
        }

if (GetOptions('...')) {
        Subject (options);
        }
else {
        $results = Subject(test data);
        assert ($results);
        }

If you call the file with arguments, it does its thing. But if you call
the file without arguments, it tests itself, using assert() et al from 
Test::Unit.

The examples for Test::Unit force one to create a module, create a test 
module, and invoke it in TestRunner by name. Because my testee does not 
need to be a module, this would add clutter.

How minimal can we get?

-- 
  Phlip
           http://flea.sourceforge.net
  --  Personally qualified to snub Mensa  --

[Perlunit-devel] New maintainer required

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

As just mentioned on perlunit-users, my new job doesn't require the
use of PerlUnit so I basically have next to no time to maintain it :-(
So if someone would like to take over, please get in touch - I'd be
really grateful.

I'll still hang around to answer questions, since the code base is not
the easiest thing to understand.  I never ignore questions (and in
fact still have a small backlog to get through), but responses to
questions will invariably take a while though, unless you want to pay
me for support, in which case I can escalate the priority.

Adam

-- 
## Adam Spiers ## musician & hacker ## me...@ad... ## http://tigerpig.org
$@=>$_=q^*{$Just =bless{},'$another ';"\$Perl \::$hacker,"}=sub{print$%[$.++];$
},eval join+v45.62,(q)$q ))x v54^,s.(?<=\$)\w*[\s,].f if+push@%,$&.sixmegs,eval

Re: [Perlunit-devel] Class::Inner

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

Philip King <em...@ch...> writes:

> Seems pretty sketchy for Unit::Test to depend on 0.1
> software (Class::Inner).  There has been *one* release,
> and that was over a year ago.  Come on, folks...
>
> Here is my "make test" for Class::Inner.
> PERL_DL_NONLAZY=1 /usr/local/bin/perl -Iblib/arch
> -Iblib/lib -I/usr/lib/perl/5.6.1
> -I/usr/share/perl/5.6.1 -e 'use Test::Harness
> qw(&runtests $verbose); $verbose=0; runtests @ARGV;'
> t/*.t
> t/basic.............FAILED tests 1-13
>                            Failed 13/13 tests, 0.00%
>                            okay
>
> Failed	13 out of 13 tests!  No thanks, sticking with
> older versions of Unit::Test.

You know, I'm always somewhat bemused by those tests failing. Whenever
I run the tests under 5.6.1 installation of perl the tests pass with
flying colours. What version of Test::More do you have installed.

> (At what point in the enhancements of Unit::Test was it
> determined that an alpha implementation of inner classes
> was necessary???)

When we spun the internal Unit::Test Inner Class implementation off
into a standalone package.

-- 
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?