Re: [Perlunit-users] PerlUnit Development

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

On Sun, Feb 19, 2006 at 03:24:13PM -0600, Joi Ellis wrote:
> On Sun, 19 Feb 2006, Matthew Astley wrote:
> > On Sat, Feb 18, 2006 at 02:14:13AM -0600, Joi Ellis wrote:

> > 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.
> 
> Is there a specific bug list you want me to look at?  [...]

No, I understood that you had found new bugs and fixed them.  So they
won't be on any bug list...  I don't need bug reports, I was just
after some text to put in the changelog.

> > Failing this, we'll just have a slightly vaguely changelog.

8-)


> > > 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?  [...]
> 
> Whatever you like.  I'm not sure how much time I can devote to it,

The first thing to do is get whatever you would like to send into the
SF tracker (or somewhere else) so it doesn't ... fade away.

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

Sent?  I haven't seen your changes yet, did I miss them?  I looked in
the SF patch tracker but can't see anything.

I think this is a perfectly valid approach to tweaking files when you
want version control before you submit the patch.  I guess it's why
Arch, SVK and others are popular.

> I could probably generate some patch files but it may take me some
> time, [...]

That'd be good.  Or just upload a tarball of the RCS ",v" files and
your ChangeLog, or whatever you sent last time.  I can deal with
those.

> > 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 prefer the SF tracker.  Actually I would be most happy with a
redirection from rt.cpan.org to the SF tracker, there's no merit in
having two bug systems for one package.  8-(


> > > I've created a subclass of TestCase.pm that includes versions of
> > > tests copied from Test::More as well.
[...]
> 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.

OK.  If you're willing to contribute it too then perhaps I can pick
stuff out of it as I get to reorganising the assertion code.


> [...] 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.

Ah yes, I have some like this.  Chaos when Carp.pm loads afterwards.
Sigh.

While the patch is open, feel free to just append another pair of
(file + comment) to it.  I guess I should get another release out soon
after, so you can have 0.26 do what you're expecting.


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

Well if you don't get time, you can just say it's the maintainer's
job.  8-]



> Indeed.  It occurs to me that one could use the tests provided with
> the Test::Harness module under t/sample-tests.

Neat idea, I've added this to my TODO.


> > [...] plus at least one slightly scary bug (is_numeric,
> > rt.cpan.org #16130) in the queue already.

> [...]
> 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.

True it's not a PU issue, but I think it's important for test
portability - the sort of thing the framework should warn the user
about.


Thanks for the extra info and ideas,

Matthew  #8-)