[tap-l] Potential Perl Review article

[Jeremiah C. Foster]

Hello!

	I am about to send an article to brian d. foy for the Perl Review on
TAP. I thought I would post it here for comments and criticism. I am
posting it in chunks hopefully making it more likely to be read. 

First chunk:

Introduction
____________

        "Unit testing is not optional because working software is not
optional."[0] -- From a job posting

        Why should you care about testing? Well you shouldn't. Unless,
of course, you want your software to work. If you hack a little code,
run the code to check its output, then you are testing. So why not
preserve those small tests in code and run it against your new module or
program? If you do that, you will find that you catch a lot of
unexpected bugs and learn more about how things work. Testing is an
integral part of perl, as anyone who has programmed in perl for a while
will tell you. When you add a new module from CPAN and you see all those
"ok" messages shoot by, those are from various tests built into the
module you are downloading. In fact the "ok" is the fundamental unit of
perl testing showing how simple the testing syntax of perl is. If you
contribute to CPAN, your software will enter a matrix of testing; from
CPANTS (The CPAN testing service), to tests measuring "kwalitee", to
CPAN testers at perl.org, to end users who will leave reviews on CPAN
ratings - your code will be very public and well tested.

        Of course, you may be a seasoned software designer, forced by
employers and habit to run tests. You want to run your tests in an
automated fashion but you don't want to sift through the voluminous
output of the test log - you want just the juicy bits; did my tests pass
or fail?

        Whether you're a n00b or seasoned vet, TAP is the perfect thing
for your toolkit. TAP is the "Test Anything Protocol" designed to run
your tests and report back to you the relevant info you want - and only
that. It is flexible enough to give you a complete picture of what is
going on, but terse enough not to weigh you down with a novel thick
enough to stun an ox every time you run your tests. TAP is a reporting
layer between you and your tests.

        This reporting layer is agnostic as it were: it does not care
what language your test is written in, as long as your program produces
proper TAP output. So you can use the best tool for the job at hand. You
can use a variety of programming languages and mix them together and TAP
will still be able to check and report back the output. In fact we are
going to use both perl and shell script (bash) to demonstrate TAP in
this article showing how flexible it can be.

       TAP is useless of course without a test to report on, so lets
create our first test. Starting with something simple for the purpose of
this article we'll write a perl script that checks which operating
system we are operating under. This type of test might be useful for
your perl script since resources can be located in different places
depending on operating system. To get the operating system, we are going
to use Perl's built in variable $^0. Using Perl's built in variable for
the OS helps ensure that we are going to be as cross-platform as
possible since there are perl porters and other wizards working to
ensure perl works on as much hardware as possible, let them do the heavy
lifting for us. 



Jeremiah