Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jarich (4909)

  (email not shown publicly)
AOL IM: ManningBear (Add Buddy, Send Message)

I run Perl Training Australia [] with pjf [] and do a lot of the course writing and maintenance. I also organise the courses we run, so if you want one, just ask. I hang around a bit on Perlmonks [] and also help run Melbourne Perl Mongers [].

Journal of jarich (4909)

Tuesday September 22, 2009
12:23 AM

Wanted: something needing testing

[ #39662 ]

Despite loving programming, I don't find much opportunity to do much of it at the moment. Sure there are short-term consulting contracts and endless re-writes of our course answers, but that hardly counts. I'm also finding it a challenge to be inspired by a few things that I kind of should do but which aren't essential. For example how we handle bookings could be better automated, but until we quadruple the number of courses we run, the parts which are manual aren't really much of a problem.

I used to love debugging, but I don't have a lot of real world experience writing tests. I can teach how to write simple tests for simple cases, but I haven't really gotten my hands dirty writing lots of tests on an interesting system.

So this is what I want. I want a module that has some tests, but needs a whole bunch more. It would make me especially happy if it came with a spec' but that seems kind of rare in the real world, so I'll settle for enough documentation that I understand what's going on. I don't want to have to read a bunch of RFCs and all the code before I understand things enough to write some tests; but I'm willing to read an RFC and some code. I don't want to randomly pick a module from CPAN, I'd rather work with someone who actively wants help adding tests to their module. I'm very happy to use CVS or git; I'm very happy to join a mailing list; I'm very happy to write tests for bugs in RT; I'm very happy to provide patches if you don't use CVS or git. I will ask lots of questions and I will want feedback on my tests including areas you think I've missed or a nod to a job well done.

Anyone got a module of which you've been meaning to improve the test suite? I'm especially happy to help with anything in alias's top 100 lists.

I'm also only going to pick one module, for the time being, and it might not be one that gets requested here. If there's lots of interest, I might take this list along to the next Melbourne PM bug-finding night, but this request is not a promise that I'll work on your module. Sorry.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • PPI is reasonably well testing generally, but lacks depth out around the edges of the API in the various PDOM classes. Almost all the methods are exceptionally well documented, but haven't been stressed enough.

    And testing can be done incrementally one module at a time. Just make a fragment of Perl code with all the different variations of something (a loop, a magic variable, a scalar, whatever), make a PPI::Document object, then check that all the appropriate elements return the appropriate values.

    Padre is