perlunit-devel — PerlUnit development mailing list

[Perlunit-devel] perunit-commits

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

I've created a perlunit-commits mailing list and set up a loginfo
entry to get any commit notifications mailed to the list. 

Need to do some voodoo to make sure it only gets commits mailed to it,
and it's currently not visible from the project page, but if you could
subscribe my mailing per...@li... that would
be a good thing.


-- 
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] many new commits

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

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

> OK, things are moving fast around here ;-) Today has been another busy
> day on the PerlUnit front, and I'm finally beginning to feel really
> happy with the way the API is looking.  Here's the log of the most
> interesting commit:
>
>  some major improvements:
>   - fixed the existing suite-building API, extended it, documented it fully,
>     added/improved tests for it
>   - reintroduced Test/Unit.pm, this time as a placeholder for $VERSION
>     and some introductory pod containing pointers to the other modules
>   - massive refactoring of Test::Unit::Loader
>   - factored out Test::Unit::Suite::_warning into Test::Unit::Warning, so
>     it could be used elsewhere
>   - fixed NoTestCaseClass test
>
> Have a look at the new pod for TestSuite in particular, and let me
> know what you think.  As far as I'm aware, I haven't broken any
> backwards compatability anywhere, and all the tests should run more
> cleanly than ever.  However, I have changed a lot of stuff, so it
> would be appreciated if people could at least try a `make test'.

You're getting to work on this during office hours aren't you?

-- 
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] many new commits

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

OK, things are moving fast around here ;-) Today has been another busy
day on the PerlUnit front, and I'm finally beginning to feel really
happy with the way the API is looking.  Here's the log of the most
interesting commit:

 some major improvements:
  - fixed the existing suite-building API, extended it, documented it fully,
    added/improved tests for it
  - reintroduced Test/Unit.pm, this time as a placeholder for $VERSION
    and some introductory pod containing pointers to the other modules
  - massive refactoring of Test::Unit::Loader
  - factored out Test::Unit::Suite::_warning into Test::Unit::Warning, so
    it could be used elsewhere
  - fixed NoTestCaseClass test

Have a look at the new pod for TestSuite in particular, and let me
know what you think.  As far as I'm aware, I haven't broken any
backwards compatability anywhere, and all the tests should run more
cleanly than ever.  However, I have changed a lot of stuff, so it
would be appreciated if people could at least try a `make test'.

[Perlunit-devel] more TestSuite/API issues

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

Ah, I think I broke something (else).  TestSuite used to read:

  sub new {
[snip]
    return $classname->suite if eval {$classname->can('suite')};

[snip]

=head1 SYNOPSIS

[snip]

       # get and add an existing suite
       $suite->add_test(Test::Unit::TestSuite->new("MyModule::Suite_1"));

Hmm.  I'm fixing that.  While I'm at it, I intend to support

       $suite->add_test('MySuite');

and

       $suite->add_test('MyTestCase');

which are much more convenient to write and easier to read.  This will
allow the simplest way of building suites yet, which I've been
hankering after for a while now:

  package MySuite;

  use base 'Test::Case::TestSuite';

  sub subtests { qw(MySuite2 MyTestCase) }
  sub name     { 'foo'                   }

It makes sense to use Test::Unit::Loader to do the work of ensuring
that the correct stuff gets compiled (MySuite2 and MyTestCase in the
example immediately above), so I've been looking at
Test::Unit::Loader.  It has some code which puzzles me, e.g.

    if ($test_case->can("suite")) {
        print "$test_case has a suite() method\n" if DEBUG;
        return $test_case->suite();
    }

Surely no test case will have a suite() method?  Only test suites have
a suite() method.  Also, the pod claims that the module handles
testcase class names, Test::Harness style test files, and directory
names, but makes no mention of handling test suites, even though it
does handle test suites for the benefit of TestRunner and HarnessUnit.

I'll try to address all this now.

Re: [Perlunit-devel] compile errors and Loader

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

Adam Spiers (ad...@sp...) wrote:
> I had the idea of creating a TestCase::_singleton class, so at
> run-time the fragments could be blessed into a class which would
> inherit from this, but then I realised that this would mean either
> changing @MyTestCase::ISA dynamically, which is too awful to
> contemplate, or ending up with the fragments not being blessed into
> MyTestCase, which isn't nice either.  Hmm, maybe they could be blessed
> into MyTestCase::_singleton which ISA MyTestCase; that would be the
> best of both worlds?

I can't yet think of any applications of this yet other than it making
things clearer when a PerlUnit developer inserts some debugging into
the code like 'warn Dumper($suite);'.  Even that small reason is
worthwhile IMO though; it would have saved me a good few hours at one
time ...

In fact the following inheritance chain would be better:

  MyTestCase::_singleton ---> TestCase::_singleton
                         \
                          --> MyTestCase --> TestCase

so that you could then do tests like

 if (eval { $testcase->isa('TestCase::_singleton') }) {

if you wanted.

Re: [Perlunit-devel] update and copyrights question

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

Piers Cawley <pdc...@bo...> writes:

> Adam Spiers <ad...@sp...> writes:
> 
> > OK, a few more commits gone/going in.  The only one of real interest
> > so far is that I renamed Test::Unit to Test::Unit::Procedural, as we
> > already planned.
> >
> > Next up (today with luck) is tackling the 3 class design-related
> > issues I mentioned in my last post.  I'm not going to do anything
> > which breaks existing API though, just things which improve it.
> >
> > Another cosmetic issue I'd like to address is a bit delicate.  We
> > currently have copyrights, licenses, and out of date author
> > attributions in pretty much every file in the distribution.  This is
> > messy, and a pain to maintain.  What I would like to see is moving of
> > all the copyrights and credits into one or two files (COPYING or
> > LICENSE or AUTHORS, say), and then to change the licensing/credit bits
> > and pieces in all the other files into something which refers to that
> > one file, and also states that none of the files should be distributed
> > separately, only as an entire package, thereby preventing the
> > copyright-containing file from being disassociated from the others.
> > However, I suspect we may need to ask permission from individuals to
> > do this, since it would mean reassigning the copyrights of various
> > files.  For example, currently TestSuite.pm is (c) Christian, but
> > TestLoader.pm is (c) Brian Ewins.  What I'm suggesting would
> > presumably make both files copyrighted by the entire group of PerlUnit
> > developers past and present.  However, IANAL and I've never really
> > thought before about how projects' collective copyrights work.
> 
> I like the idea of keeping everything copyright the PerlUnit Dev Team
> (or whatever), but I do think we need to get Christian and Brian's
> consent. 

I give my consent entirely to the idea of making everything copyright
the PerlUnit Dev Team.

> 
> > Or maybe it's simpler to keep the existing copyrights, but move all
> > the credits into one file.  Then the copyrights can stay as is, and we
> > only have one place where we need add credits when people send in
> > patches or commit contributions.
> 
> I believe Perl itself is copyright Larry as the original author (but
> the copyright date keeps extending) and then then have an AUTHORS file
> for everyone who's ever submitted a patch. 
> 
> I like this approach. Assuming we get the assignment from Christian
> and Brian, I assume we could do:
> 
> Copyright (c) 199X-2001 Christian Lemburg and Brian Ewins
> Modifications Copyright 2001-X The PerlUnit Dev Team. 
> 

Also totally OK by me.

> Any new files would be
> 
> Copyright (c) 2000- The PerlUnit Dev Team.
> 
> Not sure how this stacks up legally though.

I really don't know about the legal status of a sourceforge group.
But surely this issue has been tackled before. I'd vote for a look at
some major sourceforge group efforts, and see what they do.

The Perl approach mentioned above also has its merits, mainly that the
copyright is (1) attributable to a single defined legal person and (2)
still the work is attributed to the whole of the persons that have
contributed. For a pragmatic short term solution, this might be the
way to go. 

Christian

> 
> -- 
> 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 mailing list
> Per...@li...
> https://lists.sourceforge.net/lists/listinfo/perlunit-devel

[Perlunit-devel] Something broke

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

I'm not sure when, but the last round of commits seems to have broken
t/try_examples.t. I'll take a look at that on the train.


-- 
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] compile errors and Loader

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

Adam Spiers (ad...@sp...) wrote:
> Problem 1: 
> 
> In JUnit, you can do
> 
>   TestSuite suite= new TestSuite();
>   suite.addTest(new MoneyTest("testMoneyEquals"));
> 
> where MoneyTest extends TestCase.  In PerlUnit, this does not work
> (for me, at least):
> 
>   my $suite = Test::Unit::TestSuite->empty_new();
>   $suite->add_test(MoneyTest->new("testMoneyEquals"));
> 
> where MoneyTest ISA Test::Unit::TestCase.  I don't see any
> documentation which suggests it should work, but from looking at the
> code, it seems it should work.  Maybe just a bug somewhere?  Needs to
> be fixed before 1.0.

I was wrong about this, it works fine.

> Problem 2:
> 
> In PerlUnit, there is no way of creating a new suite by inheriting
> from Test::Unit::TestSuite.  This means that all TestSuites are
> "anonymous" instances of the Test::Unit::TestSuite class itself,
> i.e. they're not blessed into the relevant package.  That means that
> there's currently no way of retrieving the name of the package which
> built the suite.  Baaaaad.
> 
> Solution:
> 
> Rewrite new() and empty_new() to support proper inheritance, while
> still allowing the old suite() method way.  Actually, the old way only
> makes sense when embedding tests within the classes they are testing,
> so really it should be renamed to test_suite().  This solution
> involves API changes, so needs to be done before 1.0.

Done and committed!  This turned out to be a relatively small change
which IMHO made the TestSuite code substantially clearer and simpler,
and I think should also pave the way towards big improvements in how
we can build suites.  More to come on that soon.  I didn't rename all
suite() methods to test_suite(), so the old API should still work
perfectly.  Please test ...

> Problem 3:
> 
> To our eyes, the JUnit API and design which PerlUnit copies is
> fundamentally confusing in its definition of `test case'.  It states
> that a test case is a series of test methods with some fixture, but
> during the method extraction phase of building of a suite, something
> funny happens: the test case is "fragmented" into multiple instances
> of itself, each one containing a single method (once for each test
> method in the test case), and each one also containing the same
> fixture as the original multi-test test case.  To compound the
> confusion, those fragmented test cases are then collated into a test
> suite.
> 
> In other words, the object hierarchy that the end user understands and
> to a certain extent constructs, does *not* correspond to the object
> hierarchy which is operated on by the framework code at test runtime.
> The user thinks of groups of test methods with common fixture, and
> presumably calls such a group a `test case'.  However, the framework
> code ends up running a group of test methods as a test suite which
> contains test case singletons or "fragments".  This happens behind the
> scenes, so it's not a disaster for the user, but this failure to
> distinguish between singleton test cases and test case groups is a
> PITA for framework developers (well, it confused the hell out of us
> two at least).
> 
> Solution:
> 
> The XUnit design has probably been around too long to be able to do
> much about this other than make sure it's well documented :-(

I had the idea of creating a TestCase::_singleton class, so at
run-time the fragments could be blessed into a class which would
inherit from this, but then I realised that this would mean either
changing @MyTestCase::ISA dynamically, which is too awful to
contemplate, or ending up with the fragments not being blessed into
MyTestCase, which isn't nice either.  Hmm, maybe they could be blessed
into MyTestCase::_singleton which ISA MyTestCase; that would be the
best of both worlds?

Re: [Perlunit-devel] update and copyrights question

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

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

> OK, a few more commits gone/going in.  The only one of real interest
> so far is that I renamed Test::Unit to Test::Unit::Procedural, as we
> already planned.
>
> Next up (today with luck) is tackling the 3 class design-related
> issues I mentioned in my last post.  I'm not going to do anything
> which breaks existing API though, just things which improve it.
>
> Another cosmetic issue I'd like to address is a bit delicate.  We
> currently have copyrights, licenses, and out of date author
> attributions in pretty much every file in the distribution.  This is
> messy, and a pain to maintain.  What I would like to see is moving of
> all the copyrights and credits into one or two files (COPYING or
> LICENSE or AUTHORS, say), and then to change the licensing/credit bits
> and pieces in all the other files into something which refers to that
> one file, and also states that none of the files should be distributed
> separately, only as an entire package, thereby preventing the
> copyright-containing file from being disassociated from the others.
> However, I suspect we may need to ask permission from individuals to
> do this, since it would mean reassigning the copyrights of various
> files.  For example, currently TestSuite.pm is (c) Christian, but
> TestLoader.pm is (c) Brian Ewins.  What I'm suggesting would
> presumably make both files copyrighted by the entire group of PerlUnit
> developers past and present.  However, IANAL and I've never really
> thought before about how projects' collective copyrights work.

I like the idea of keeping everything copyright the PerlUnit Dev Team
(or whatever), but I do think we need to get Christian and Brian's
consent. 

> Or maybe it's simpler to keep the existing copyrights, but move all
> the credits into one file.  Then the copyrights can stay as is, and we
> only have one place where we need add credits when people send in
> patches or commit contributions.

I believe Perl itself is copyright Larry as the original author (but
the copyright date keeps extending) and then then have an AUTHORS file
for everyone who's ever submitted a patch. 

I like this approach. Assuming we get the assignment from Christian
and Brian, I assume we could do:

Copyright (c) 199X-2001 Christian Lemburg and Brian Ewins
Modifications Copyright 2001-X The PerlUnit Dev Team. 

Any new files would be

Copyright (c) 2000- The PerlUnit Dev Team.

Not sure how this stacks up legally though.

-- 
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] copyrights

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

Matthew Astley (mc...@us...) wrote:
> > > Your point though, is (?) that it's the delicacy of refactoring the
> > > credits which is the problem, not the legality.
> > 
> > No, it's the legality I was worried about, since the refactoring is
> > still giving everyone the credit they deserve.
> 
> Digressing slightly, it occurred to me we should perhaps have a
> perldoc file, Test::Unit::Credits, or something? perldoc it > CREDITS
> at tarball time?

Could do, I'd prefer to keep it as text though, because that seems to
be the CPAN convention.

Re: [Perlunit-devel] copyrights

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

On Tue, Nov 27, 2001 at 04:58:51PM +0000, Adam Spiers wrote:
> Matthew Astley (mc...@us...) wrote:
> > (Yes, I'm still here .. sorry I've been so quiet, I'm mostly using
> > JUnit instead, at the moment!)
> 
> Traitor! ;-)

*cower* I'm sorry, I didn't have time to port PerlUnit to Java! 9-)

> > Your point though, is (?) that it's the delicacy of refactoring the
> > credits which is the problem, not the legality.
> 
> No, it's the legality I was worried about, since the refactoring is
> still giving everyone the credit they deserve.

Digressing slightly, it occurred to me we should perhaps have a
perldoc file, Test::Unit::Credits, or something? perldoc it > CREDITS
at tarball time?

> > If the new file structure serves the same legal purpose then surely
> > you're only obliged to ask each author out of politeness?
> 
> That's the thing, I'm not sure it does, because it would in effect
> take a file copyrighted by person A and make it copyrighted by persons
> A, B, C ...  I can't imagine anyone caring, but it's probably worth
> thinking about anyway.

Hmm. Well, presumably most people fall into one of two categories,

 - did enough stuff to everything to get credit for the whole

 - did few enough enumerable jobs that specific credit won't take too
   much space

What's the current favourite practice for assigning copyright? Split
it into lots of pieces so the Bad People can't wrestle it from an
individual, or consolidate so you can easily hand it over to the Good
People? Hmm, we're going to end up in a licence-size contest aren't
we? 8-(

Am I misguided in thinking that assigning credit for parts of the
project is equivalent to assigning (joint) copyright ownership for
those parts?


Matthew  #8-)

Re: [Perlunit-devel] copyrights

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

Matthew Astley (mc...@us...) wrote:
> (Yes, I'm still here .. sorry I've been so quiet, I'm mostly using
> JUnit instead, at the moment!)

Traitor! ;-)

> On Tue, Nov 27, 2001 at 02:49:39PM +0000, Adam Spiers wrote:
> Surely the main thing is that the respective authors maintain their
> copyright over & credit for the project? In which case, having each
> individual file point at the credits/licence and then putting a decent
> history in that file should do the trick? IANAL...

Well yes, I'm sure that's the main thing as far as anyone is
concerned.  However...

> Your point though, is (?) that it's the delicacy of refactoring the
> credits which is the problem, not the legality.

No, it's the legality I was worried about, since the refactoring is
still giving everyone the credit they deserve.

> If the new file structure serves the same legal purpose then surely
> you're only obliged to ask each author out of politeness?

That's the thing, I'm not sure it does, because it would in effect
take a file copyrighted by person A and make it copyrighted by persons
A, B, C ...  I can't imagine anyone caring, but it's probably worth
thinking about anyway.

Re: [Perlunit-devel] update and copyrights question

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

(Yes, I'm still here .. sorry I've been so quiet, I'm mostly using
JUnit instead, at the moment!)

On Tue, Nov 27, 2001 at 02:49:39PM +0000, Adam Spiers wrote:

> Another cosmetic issue I'd like to address is a bit delicate. We
> currently have copyrights, licenses, and out of date author
> attributions in pretty much every file in the distribution.
> [...]
> What do you all think?

I agree entirely. I haven't contributed very much of course, but I'm
happy to be moved out to a credits file. 9-)

Surely the main thing is that the respective authors maintain their
copyright over & credit for the project? In which case, having each
individual file point at the credits/licence and then putting a decent
history in that file should do the trick? IANAL...


Your point though, is (?) that it's the delicacy of refactoring the
credits which is the problem, not the legality.

If the new file structure serves the same legal purpose then surely
you're only obliged to ask each author out of politeness? Then if you
don't get a reply after a few weeks, the person probably doesn't care?


Matthew  #8-)

[Perlunit-devel] update and copyrights question

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

OK, a few more commits gone/going in.  The only one of real interest
so far is that I renamed Test::Unit to Test::Unit::Procedural, as we
already planned.

Next up (today with luck) is tackling the 3 class design-related
issues I mentioned in my last post.  I'm not going to do anything
which breaks existing API though, just things which improve it.

Another cosmetic issue I'd like to address is a bit delicate.  We
currently have copyrights, licenses, and out of date author
attributions in pretty much every file in the distribution.  This is
messy, and a pain to maintain.  What I would like to see is moving of
all the copyrights and credits into one or two files (COPYING or
LICENSE or AUTHORS, say), and then to change the licensing/credit bits
and pieces in all the other files into something which refers to that
one file, and also states that none of the files should be distributed
separately, only as an entire package, thereby preventing the
copyright-containing file from being disassociated from the others.
However, I suspect we may need to ask permission from individuals to
do this, since it would mean reassigning the copyrights of various
files.  For example, currently TestSuite.pm is (c) Christian, but
TestLoader.pm is (c) Brian Ewins.  What I'm suggesting would
presumably make both files copyrighted by the entire group of PerlUnit
developers past and present.  However, IANAL and I've never really
thought before about how projects' collective copyrights work.

Or maybe it's simpler to keep the existing copyrights, but move all
the credits into one file.  Then the copyrights can stay as is, and we
only have one place where we need add credits when people send in
patches or commit contributions.

What do you all think?

[Perlunit-devel] He did a bad, bad thing

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

So, on Saturday I didn't write any code because I was spending the
last full day with my wife before she went off on a course for a week,
and then we went to see Harry Potter.

And on Sunday I didn't write any code because I saw my wife off then
went to my nephew's first birthday party in the afternoon. And in the
evening I didn't write any code because, just before I went to my
nephew's first birthday party, I bought a copy of Civ III..

And this morning on the train I didn't write any code because I was
getting an extra hour's sleep to bring my total night's sleep to, um,
4 hours.

And on the train tonight I'll probably not be writing any code because
I'm doing a presentation on the Perl Refactoring Engine on Thursday
and I've promised some functionality I haven't implemented yet...

Hmm... Where does the time go?

-- 
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] compile errors and Loader

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

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

> Piers Cawley (pdc...@bo...) wrote:
>> Adam Spiers <ad...@sp...> writes:
>> > Test::Unit::Loader is doing all the work of compiling in suites and
>> > cases etc., and mostly works very nicely.  However, the load() method
>> > has an oddity:
> 
> ...
> 
>> > What was the reasoning behind hiding those "Can't locate" errors?
>> 
>> Not sure.
>> 
>> Maybe the idea is to carry on and run what you can, but it seems like
>> it's not winning us anything. If you change it to die, do any tests
>> fail that would otherwise have passed. If no tests fail, write a test
>> to exercise the new behaviour, and commit the changes. 
> 
> Done.

I can cope with this project management malarkey. You get to tell
people what needs doing, and it gets done. I'm not sure I've written a
line of code since I bought the maintainer's hat. 

I intend to rectify that this weekend.

-- 
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] compile errors and Loader

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

Piers Cawley (pdc...@bo...) wrote:
> Adam Spiers <ad...@sp...> writes:
> > Test::Unit::Loader is doing all the work of compiling in suites and
> > cases etc., and mostly works very nicely.  However, the load() method
> > has an oddity:

...

> > What was the reasoning behind hiding those "Can't locate" errors?
> 
> Not sure.
> 
> Maybe the idea is to carry on and run what you can, but it seems like
> it's not winning us anything. If you change it to die, do any tests
> fail that would otherwise have passed. If no tests fail, write a test
> to exercise the new behaviour, and commit the changes. 

Done.

Re: [Perlunit-devel] compile errors and Loader

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

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

> Test::Unit::Loader is doing all the work of compiling in suites and
> cases etc., and mostly works very nicely.  However, the load() method
> has an oddity:
> 
>     } elsif ($@ !~ /^Can\'t locate .* in \@INC \(\@INC contains/) {
>         die $@;
>     } else {
>         print "Debug: ".$@ if DEBUG;
>     }
> 
> which means that if your test case tries to use another module
> unsuccessfully (e.g. if the module name has a typo), then it falls
> through the above block without doing anything (except outputting some
> debugging if DEBUG is on).  That means the user sees:
> 
>   >> Tests::GGconfig
>   (This error is expected) Suite class Tests::GGconfig not found: Can't
>   locate GGconfg.pm in @INC (@INC contains: .....
> 
> which is misleading.  Changing that code to
> 
>     } else {
>         die $@;
>     }
> 
> yields:
> 
>     >> Tests::GGconfig
>     Can't locate GGconfg.pm in @INC (@INC contains: .....
> 
> which is exactly what the user needs to see.  What was the reasoning
> behind hiding those "Can't locate" errors?

Not sure.

Maybe the idea is to carry on and run what you can, but it seems like
it's not winning us anything. If you change it to die, do any tests
fail that would otherwise have passed. If no tests fail, write a test
to exercise the new behaviour, and commit the changes. 

Hmm... maybe we could use a 'run a new perl with this code' type test
method...

-- 
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] runner state

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

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

> OK, I've committed my runner state patch.  It adds a new Runner base
> class which is an appropriate place for runner state common between
> all runners.
> 
> Also committed is a very basic example of how it can be useful: filter
> tokens.  To try it out, add something like this to one of your test
> cases:
> 
>     sub filter {{
>       'slow'        => [ 'test_a_slow_one', 'test_another_slow_one' ],
>       'really_slow' => [ 'test_wow_really_slow' ],
>     }}
> 
> then you can filter out slow tests via
> 
>     my $runner = new Test::Unit::TestRunner();
>     $runner->filter(qw/slow really_slow/);
>     $runner->start($class);
> 
> You can have more flexibility if you override filter_method() instead
> of filter().  The API is such that a test $method will be skipped if
> there is any token $token active for which
> 
>   $test->filter_method($token, $method)
> 
> returns true.  The default behaviour is implemented in T::U::Test, and
> it simply looks at the data structure returned by filter().
> 
> I don't like the way that filter_method() has to be implemented in
> T::U::Test rather than T::U::TestCase.  This is because individual
> tests within a suite are currently TestSuite objects rather than
> TestCase objects.  Is there a good reason for this?  It feels very
> ugly.

Ah yes, this is the scary introspection stuff that I've been somewhat
worried about in how this hangs together. I need to do some *more*
code reading and maybe a spike, see what the code tells me.

-- 
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] (no subject)

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

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

> Piers Cawley (pdc...@bo...) wrote:
>> Adam Spiers <ad...@sp...> writes:
>> >Piers Cawley (pdc...@bo...) wrote:
>> >> Well, it's sort of dependent on where you run the script from.
>> >> Actually I'm more inclined to stick the *modules* in t/tlib (I'll
>> >> explain why it has to be tlib in a minute) and then do 
>> >> 
>> >>     use lib 't/tlib', 'tlib';
>> >> 
>> >> So that you can run the tests from either the project root or from
>> >> inside the t directory. It has to be tlib instead of lib to avoid
>> >> using the files in lib/* rather than blib/*.
>> > 
>> > Yep, sounds good.  It doesn't look like there's any hook in MakeMaker
>> > so we could persuade it to add these to @INC directly, hmph.  Although
>> > doing it that way would break running the tests directly (isn't that
>> > deprecated however?)
>> 
>> Dunno about deprecated, it can be damned useful.
>> 
>> > I can do this right now if you want me to.
>> 
>> Go to it.
> 
> Done and committed.  Tests all pass for me; hope I haven't broken
> anything.

Nope, you fixed something. It works with no warnings under 5.7.2 now.
Which worries me strangely...

Oh yes, I've added doc/TODO to the MANIFEST

-- 
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] compile errors and Loader

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

Test::Unit::Loader is doing all the work of compiling in suites and
cases etc., and mostly works very nicely.  However, the load() method
has an oddity:

    } elsif ($@ !~ /^Can\'t locate .* in \@INC \(\@INC contains/) {
        die $@;
    } else {
        print "Debug: ".$@ if DEBUG;
    }

which means that if your test case tries to use another module
unsuccessfully (e.g. if the module name has a typo), then it falls
through the above block without doing anything (except outputting some
debugging if DEBUG is on).  That means the user sees:

  >> Tests::GGconfig
  (This error is expected) Suite class Tests::GGconfig not found: Can't
  locate GGconfg.pm in @INC (@INC contains: .....

which is misleading.  Changing that code to

    } else {
        die $@;
    }

yields:

    >> Tests::GGconfig
    Can't locate GGconfg.pm in @INC (@INC contains: .....

which is exactly what the user needs to see.  What was the reasoning
behind hiding those "Can't locate" errors?

[Perlunit-devel] runner state

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

OK, I've committed my runner state patch.  It adds a new Runner base
class which is an appropriate place for runner state common between
all runners.

Also committed is a very basic example of how it can be useful: filter
tokens.  To try it out, add something like this to one of your test
cases:

    sub filter {{
      'slow'        => [ 'test_a_slow_one', 'test_another_slow_one' ],
      'really_slow' => [ 'test_wow_really_slow' ],
    }}

then you can filter out slow tests via

    my $runner = new Test::Unit::TestRunner();
    $runner->filter(qw/slow really_slow/);
    $runner->start($class);

You can have more flexibility if you override filter_method() instead
of filter().  The API is such that a test $method will be skipped if
there is any token $token active for which

  $test->filter_method($token, $method)

returns true.  The default behaviour is implemented in T::U::Test, and
it simply looks at the data structure returned by filter().

I don't like the way that filter_method() has to be implemented in
T::U::Test rather than T::U::TestCase.  This is because individual
tests within a suite are currently TestSuite objects rather than
TestCase objects.  Is there a good reason for this?  It feels very
ugly.

Re: [Perlunit-devel] (no subject)

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

Piers Cawley (pdc...@bo...) wrote:
> Adam Spiers <ad...@sp...> writes:
> >Piers Cawley (pdc...@bo...) wrote:
> >> Well, it's sort of dependent on where you run the script from.
> >> Actually I'm more inclined to stick the *modules* in t/tlib (I'll
> >> explain why it has to be tlib in a minute) and then do 
> >> 
> >>     use lib 't/tlib', 'tlib';
> >> 
> >> So that you can run the tests from either the project root or from
> >> inside the t directory. It has to be tlib instead of lib to avoid
> >> using the files in lib/* rather than blib/*.
> > 
> > Yep, sounds good.  It doesn't look like there's any hook in MakeMaker
> > so we could persuade it to add these to @INC directly, hmph.  Although
> > doing it that way would break running the tests directly (isn't that
> > deprecated however?)
> 
> Dunno about deprecated, it can be damned useful.
> 
> > I can do this right now if you want me to.
> 
> Go to it.

Done and committed.  Tests all pass for me; hope I haven't broken
anything.

Re: [Perlunit-devel] Towards Version 1.0

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

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

> Piers Cawley (pdc...@bo...) wrote:
>> And, dammit, the framework is really useful now and creeping towards
>> maturity. I'm thinking of picking the current trunk (with a working
>> 'ok')  and tagging it 1_0_RELEASE_CANDIDATE freezing the features,
>> hammering on it to make it work with 5.7.2, writing a quick tutorial
>> pointing people at Test::Unit::TestCase and getting it up to CPAN as
>> 1.0 as soon as we're happy with it. The Roadmap for this, as I see it
>> is:
>> 
>> 1. Rename Test::Unit to Test::Unit::Procedural
>> 2. Rename Test::Unit::HarnessUnit and Test::Unit::UnitHarness
>>    Not sure what to yet, but I want to get these big API changes out
>>    of the way before we bump the version number.
>> 3. Working ok
>> 4. Working build on 5.7.2
>   5. Change suite-building API so that MySuite really ISA TestSuite,
>      and gets instantiated via new() rather than the current suite()
>      nonsense.  This is a *big* API change, but I'm utterly convinced
>      we need to do it.  I think it should be possible to keep
>      backwards compatibility, however.

Ooh yes. Definitely necessary.

>   6. If a testcase fails compilation, you currently get `Suite class
>      MyTests::Foo not found', rather than `Failed to load ...'; this
>      needs fixing.

Yup. Actually, I *think* I may have fixed that en passant. It's to do
with TU::Loader not remembering the *initial* $@ when it goes off
trying to load the class via various methods. I sometimes wonder if
we're not trying to be 'too friendly' at this point.

>   7. Stop `make test' failing when DEBUG is enabled?

Yeah, definitely a good idea.

>   8. Move test libraries out of lib/Test/Unit/tests.

Ooh yes. Very important that one.

>   9. Deal with broken base.pm in older Perls (or we could always be
>      nasty and stop supporting < 5.6, best to avoid if we can
>      though).

I love the thought of being nasty, but this doesn't seem to be a good
enough reason to break the backwards compatibility that hard. 

> None of these are big jobs, but I think they should all be done
> before 1.0 if we want the framework to gain respect and widespread
> usage; after all, many people will check out PerlUnit for the first
> time when they hear 1.0 being announced, and first impressions count
> for a lot.

Indeed. I'm already thinking of wording the announcement as well. I
want to steal some mindshare back from Test::More and its brothers.

>> Nice to have
>> 
>> 1. Test::Unit::Loader working with whole directories.
>> 2. <YOUR SUGGESTIONS HERE>
> 
>   2. Refactoring of runner classes to allow storing state in the
>      runner.  This paves the way for choosing which tests to skip in a
>      given run, which brings me on to ...

I'm not sure this isn't a 1.1 feature though.

>   3. Test filtering.  I like your Attribute::Handlers idea a lot, and
>      have a very real need for decent filtering right now.

Ah yes. This may well be a good reason for breaking backward
compatibility with earlier Perls. I can't remember what the minimum is
for Attribute::Handlersx

>   3. Rethink how the tests are split up between the t/*.t.  Currently
>      we have t/all_tests.t, which is clearly a misnomer, and we have
>      some tests for the assertion code being run from that rather than
>      from t/assert.t.

Personally I don't like all_tests.t for running in 'Test::Harness'
style. It's great to be able to do TestRunner.pl tests::all_tests if
you're working in an xUnit style, but breaking things up so that 'make
test' gives people the output they expect seems like a win to me.

It'd be *really* nice if we could do the following in foo.t

    package test::foo

    # Define some tests for this package.

    unless (caller) {
        require Test::Unit::SelfRunner;
        Test::Unit::SelfRunner->run;
    }

Which might be surprisingly easy to push in for 1.0

While I'm about it, having a 'Runner::new' that took an argument
specifying which display style to use would be nice... Get it right
and you can have it looking at ~/.perlunitrc to select the users
preference. This is probably post 1.0 though.

> Some of these could be left until after 1.0; however given that I will
> certainly be aiming to commit some of them very soon (today, tomorrow
> ...), it's probably more hassle than it's worth branching off for the
> release straight away.
> 
> I'll commit all these to doc/TODO now, and then we can twiddle with it
> as need be.

Sounds like a plan.

> Incidentally, we must remember to consult doc/release-checklist before
> making a release ...

Indeed. And I need to work out how to convince PAUSE that I'm the
maintainer now...

-- 
Piers

-- 
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] PDC_REFACTOR merged back

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

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

> Piers Cawley (pdc...@bo...) wrote:
>> Adam Spiers <ad...@sp...> writes:
>> > I use PCL-CVS under emacs (highly recommended), which amongst other
>> > things makes it trivial to keep an eye out for files which should be
>> > checked in but aren't. However for our peace of mind I've just done
>> > a fresh checkout and it's all good.
>> 
>> I really must learn PCL-CVS properly. I use it but in a desultory
>> fashion. 
> 
> I recently submitted a patch against emacs 21.1 to the maintainer,
> which makes it quite a lot nicer (IMHO ;-)  A copy follows below, in
> case you're interested.  Here is a breakdown of what it does:

[FX: Marks for future reference]

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