Re: [Perlunit-users] PerlUnit Development

[Joi E. <gy...@vi...>]

On Sun, 19 Feb 2006, Matthew Astley wrote:

> On Sat, Feb 18, 2006 at 02:14:13AM -0600, Joi Ellis wrote:
> 
> For other readers: TAP is "test anything protocol", see
> http://use.perl.org/~petdance/journal/22057

Even easier would be perldoc Test::Harness:TAP, since Test::Harness
is bundled with current perls and its documented there.

> > I've fixed some bugs, too, like HarnessUnit failing to pass any
> > useful diagnostic information back to the GUI.
> 
> It would help the changelog if you could list the bugs fixed, it may
> not be possible for me to figure this out from your changes.  Failing
> this, we'll just have a slightly vaguely changelog.

Is there a specific bug list you want me to look at?  The work I did
was mostly to make the gui usable for my particular project, but it's 
general enough.

I've looked at the bugs list on cpan and on sourceforge.  The stuff I've
address isn't mentioned in any of those that I can see.  I haven't filed any
bug reports myself.
 
> > In all, I've worked on the following classes:
> > 
> > Test/Unit/Exception.pm
> > Test/Unit/HarnessUnit.pm
> > Test/Unit/Loader.pm
> > Test/Unit/Result.pm
> > Test/Unit/Runner.pm
> > Test/Unit/TkTestRunner.pm
> > Test/Unit/UnitHarness.pm
> 
> How would you like to send these changes?  In exchange for agreeing to
> "the same terms as Perl" you can be listed in AUTHORS.  Further
> enthusiasm runs the risk of being added as a SF developer.  8-)

Whatever you like.  I'm not sure how much time I can devote to it, the
past two weeks I've been home on medical leave from my regular job so I've
had an unusual amount of spare time lately.

I already have one project on source forge, XPCGI.  Haven't touched it in
years, though.  I'm tempted to port the thing to Perl/Tk now. ;)

> Output of "cvs diff -u" plus name or date of what you started hacking
> on would suit me quite well, but it won't include new files.  Or you
> can just tarball whatever you have and let me sort it out.

Well, I got lazy and used RCS to track the changes I've made.  That's
where I got the ChangeLog I sent, with some manual edits to delete
unimportant junk comments.

I could probably generate some patch files but it may take me some time,
I get to go back to work tomorrow morning if the doctor agrees.

> Adding patch ticket(s) on Sourceforge will keep your work in view.  If
> your changes can be split by theme, sending several patch tickets with
> smaller diffs would probably help me out - if you've done a lot of
> work it may take me a while to catch up all of it.

That's a new feature since I last worked with SF.  I presume that's a 
place where outsiders can put their patches?  I could do that.  Or I could
create bug reports at cpan and upload patch files as attachments there, too.

Which do you prefer?

> > I've created a subclass of TestCase.pm that includes versions of tests
> > copied from Test::More as well.
> > 
> > Test/Unit/MyTestCase.pm
> 
> Thread fork here...
> 
> Also, a minor point on naming (sorry).  I think T:U:MyTestCase is
> unsuitable for project release because of the convention for naming
> things MyFoo in the POD, when intending to suggest that it is the
> user's own Foo under discussion.  i.e. while your code is joining the
> project you're not a Joe Public user.

No, I didn't intend MyTestCase to become part of the project, I just used
that because I wanted to keep my extensions separate.  I left it in
Test::Unit for my own organization purposes inside Komodo.

> Apart from T:U:Assert refactoring, possible solutions for the name: if
> T:U:MyTestCase only includes versions of tests copied from Test::More,
> it might be best named T:U:MoreTestCase or something like that.  Or if
> you wanted some code ownership, T:U:JoiTestCase.

I don't care about ownership much.  I added another assert last night,
using code lifted from Test::Warn and rewritten to suit Perl Unit, so now
I can capture and test for warn() and carp() from the method under test.
This isn't tested much yet and I haven't yet written a test suite for it.

> > All this still passes all of the original Perl Unit tests when my
> > custom versions are loaded.
> 
> That's always good.  Do your changes need additional testing or POD?
 
It probably wouldn't hurt me to write test cases that show how 0.25
fails to handle TAP, and make sure I've fixed the tests.

> There may be an issue here with module dependencies - it isn't fair to
> expect the user to install the whole set of "Test::* module that reads
> or writes TAP" in order to install Test::Unit.

No, it isn't.  That sort of thing can be made optional both in the install and
in the tests.  None of the changes I've made to Perl Unit classes
involve new Test::* modules.  Even MyTestCase.pm doesn't require them, it
just steals from them. ;)

I do have a mix of *.t files that use Test::More, Test::Pod, etc, which is
one reason I've been hacking on the Tk gui so much.  The gui can now 
handle output from non-Perl Unit tests in a usable fashion, which it utterly
failed to do in 0.25. 

> However, it does make a lot of sense for a perlunit developer to run
> tests against them if the project is to support them properly.  It may
> even be a good idea to keep output from old versions of such modules,
> because we can't assume the user is up-to-date without a dependency,
> and testing can be a bit special when it comes to legacy support.

> Perhaps it's best to bottle some samples of TAP (!) and distribute
> them.  Then make some additional code to require the relevant modules
> and bottle up some new TAP.

Indeed.  It occurs to me that one could use the tests provided with the
Test::Harness module under t/sample-tests.  I haven't gone to that
extreme yet, though.  I've just been fixing what didn't work for my own
project's tests.

> Testing TAP output against an assortment of code that reads it would
> be harder.

I expect a simple test for this would be to use 'prove' against the
whole test suite.  One might want to look around in Test::Harness's tests
to see if they don't already have a TAP validation test.

> 
> OK, this could get complicated.  Perhaps it's best to start with
> something, then extend it later.
> 
> > Is there any interest out there?
> 
> I'm definitely interested, and yes this does mean to the extent of
> writing tests or maybe even POD.  9-)
> 
> My roundtuitometer informs me that we have patches for TestDecorator
> and an XML (Ant compatible?) testrunner, plus at least one slightly
> scary bug (is_numeric, rt.cpan.org #16130) in the queue already.

I remember reading a bug report somewhere more general, but I don't 
remember exactly where it was.  The gist of the issue that that the 
linux libc/glibc is_numeric routine recognizes one additional format
than other unices do, so it fails the test for that routine.

If you look around on Google you can see a bunch of projects where
this particular linux "enhancement" is generating bug reports.
I'd probably just make the test check to see if its running under a 
linux kernel and adjust the test accordingly.  It's not really a
Perl Unit issue anyway.

-- 
Joi Ellis                    
gy...@vi...

No matter what we think of Linux versus FreeBSD, etc., the one thing I
really like about Linux is that it has Microsoft worried.  Anything
that kicks a monopoly in the pants has got to be good for something.
           - Chris Johnson