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-) ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Perlunit-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/perlunit-users
