[Pdx-pm] Perl Testing Clinic, 6:30 tonight @ Free Geek

Michael G Schwern schwern at pobox.com
Thu Feb 22 15:22:03 PST 2007

Selena and Gabrielle bribed me with cookies to do a little Perl Testing Clinic tonight.  I only got back into town this week and have a bunch of work to do so I didn't want it to turn into a big thing I'd have to prepare for.
That said, I'm opening it up to whomever would like to come on such short notice because it would seem a waste. [1]

The format is just to come with your testing situations which are giving you trouble and we'll see about working things out.  You should already have basic knowledge of testing, at least what's covered in Test::Tutorial, and already started to do it on your own.  Or just come to listen in.

If you do plan on coming it would be helpful to post up what you intend to ask so I have at least a little time to mull it over.

This is what Selena and Gabrielle wrote for an outline of what they'd like to know:

How do I know when I should write a test?
What tests should I have?
What perl modules help me?

Testing VS Error Checking
    - what is the difference?  When is something error checking, when should it be part of a "test suite"?
    - when do we write the test?  (before writing our functions?)
    - but we already wrote the functions, so sorry, how do we go back and write the tests?
    - inside a test, an error happens:  where it goes, how to capture it, and what to do with it

And now, for what I like to call the DEAR SCHWERN portion of the clinic:

I have several small applications that gather data from various sources
into a flat file & update/add that information to a database daily.
Issues that I'd like to test for:

* Environment/Configuration testing
    - Path to a file: a) file not there, b) permissions wrong, c) file empty, d) file has weird crap in it etc. , e) path does not exist, f) file date too old
    - passwords, keys: changed
    - input data validation - do i have all the files i need, are they in the right places, are they configured correctly

* Data export may contain bogus data (but it is mostly ok)
    - gracefully handling insert failures on rows
    - for different types of errors, have a set of different actions available

* Data export may contain valid data, but is mostly bogus
    - Example: other departments are supplying excel files, and they are creating them by hand, so a careful checking procedure is required before trying to use the files.  We do not want to wait until we're inserting rows before croaking.

* Referential Integrity in DB
    - the table I'm updating references another table; do I need to insert a new record in that other table to maintain relational integrity? 

[1]  Its really that I'm afraid to be alone in a room with icky girls!!!

More information about the Pdx-pm-list mailing list