Wise monks,

My company is facing a transition. We have been writing perl scripts-- little snippets of code to get certain text outputs-- or modifying longer programs (adding logic to affect printed text output). We have been using shell scripts to drive our processes-- the most ungodly mess you can imagine, and which varies from job to job based on who set it up, and how many years ago. The good news: we have recently purchased some new software and we are retooling our existing processes to use it, and moving from flat file to database (MySQL) data.

As we talked about designing this new framework, I timidly suggested adding testing modules to the process Up Front, and as a reward, I was tasked with researching testing, and training our developers to do it. The closest any of us have been to testing is adding print statements to code while debugging-- one of us (not me) actually uses the Perl debugger with some facility.

It's not a matter of convincing them we need to be testing-- everybody's sold on that. We are all just getting overwhelmed with where to start. I've read the posts on testing here found through Super Search, and I have printed some out to share. I've gone to CPAN and printed off several of the modules (Test::Simple, Test::More, the tutorial on testing, etc). I've been reading books on testing and software construction in general: Perl Medic, Perl Debugged, Perl testing: A Developer's Notebook , and Code Complete.

One problem is: most of us are self taught, or have only the haziest ideas about Object Oriented Programming, or writing/ using modules at all. Some things in our process are obvious- you want to test that needed files are where you expect them to be, are in the right format, and that the program generates the expected outfiles and sends them where they need to go. But-- What else? If you’re supposed to design tests before you code, what else should we be looking for?

My plan for training is to pass out some of the CPAN material on Test::Simple and Test::More, and the posts from here, and parts of the books, some of which we are buying as a company. I’m also going to touch on Perl Tidy and Perl Critic, as ways for us to enforce these coding standards we’re agreeing on. What I’m looking for from you guys is other suggestions, things I might think about, ways you’ve presented testing to programmers you’ve mentored over the years. Things you wish you’d known when you were starting out. Testing procedures you inherited when you started with a company, that you wish you could change.

We’ve this fantastic opportunity to design procedures and policies that will make our lives easier, make us better programmers, and make our company, and us, lots of money. And that is also a little overwhelming.

Many thanks in advance,

NovMonk

In reply to RFC: Perl Testing -- How to Introduce to a team by NovMonk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.