Stories
Slash Boxes
Comments
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 ]

xsawyerx (8978)

xsawyerx
  (email not shown publicly)

Journal of xsawyerx (8978)

Tuesday December 16, 2008
06:18 AM

Tests are heavenly

[ #38096 ]
TDD (Test Driven Development) is still at an early stage of developer adaption. However, in Perl it's quite common and practically demanded (though can be roughly ignored) of module writers/maintainers. Even if you do not write in a strict TDD fashion (write test, write code, refactor code, repeat), there is still much use in the plethora of testing modules available @ CPAN.

Testing while programming (or rather, before programming) is very interesting but I'll cover it in a more in-depth entry some other time. This time I just want to share something I enjoyed in this realm that made my life much easier at work.

I administer a large quantity of servers, and an even larger quantity of domains. At some point, I had to make a series of changes on every single server regarding several domains (but not necessarily all).

What I did was to write a test suite that checks the various changes. Four files: 00_dns_server_local_domains.t, 01_dns_registrar_domains.t, 02_dns_all_records.t and 03_complete_corps.t.
We've already covered I'm not good with names but basically these are in the order it takes to create them. First the DNS is checked on the servers for the local domains changes. Then the DNS is checked on the registrar for the domains, then the DNS is checked for all the records in each domain and lastly (yes, it's a word) the complete test for all the rest of the stuff that should be production.

If you use Test::More qw( no_plan ) you don't have to specify the amount of tests ahead and it will count them as it goes along. This is helpful when you don't know how much you have - in my case because each server can have a different amount of domains.

But here is where it gets interesting:
  1. The test script reads a YAML configuration file for the details
  2. It is plugged to a in-house module that parses a wiki for information about in-house resources (ips, equiptment, etc.)
  3. It allows different files to be read
  4. It allows a specific server and domains to be tested
  5. It allows a specific test to be run inside each testing suite

Thusly I can run the following line after making a specific change to a specific server for a specific check:

sawyer@gnubuntu:~/code/corps$ t/03_complete_corps.t -f domains-all.yaml -s server147 -t ptr
ok 1 - server147: single PTR [1]
ok 2 - server147: correct PTR
1..2

Basically I ran a PTR check (a part of the testing suite called 03_complete_corps.t) on a specific server called server147 that resides in a servers and domains configuration file domains-all.yaml.
This is the usage definitions:

sawyer@gnubuntu:~/code/corps$ t/03_complete_corps.t --help
t/03_complete_corps.t [ -h|--help ] [ -s|--server SERVER ] [ -f|--file YAMLFILE ] [ -r|--read-wiki ] [ -t|--test TEST ]
# No tests run!

Very nice, indeed.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.