Skip to main content

Posts

Showing posts with the label unit testing

Test::Harness, or a lesson about wheels not to be reinvented

Let’s say you have your unit tests in place, using something not particularly esoteric as Test::More . Good. Now you want something to give some color to your output, so green is Good , red is Bad and you have a quicker feedback. Time ago I wrote a quick shell script to run all the unit tests, interpret the output (in TAP format), print on screen some color output and stop the tests if something fails. The core was: function check_test_result() { red='\e[0;31m' green='\e[0;32m' end='\033[0m' result=`perl $1`; echo "$result" perl -e '{ my $input = join(" ", @ARGV); if ($input =~ /not ok/m) { exit 0; } exit 1; }' $result if [ $? -eq 0 ] then echo -e "$red Not all tests passed. FAILURE$end" exit -1 else echo -e "$green All tests passed. SUCCESS$end" fi } This works as soon as the unit tests fail (printi...

Need some constructive criticism on your code? Ask perlcritic.

perlcritic is "a static source code analysis engine", a CPAN module which can also be used as a command . An example: $ perlcritic -severity 3 src/AModule.pm Subroutine does not end with "return" at line 24, column 1. See page 197 of PBP. (Severity: 4) Return value of eval not tested. at line 32, column 5. You can't depend upon the value of $@/$EVAL_ERROR to tell whether an eval failed.. (Severity: 3) As you can see you can get extremely useful information about the sanity of your code and how much it complies to good coding practices. There are 5 different severity levels (being 5 the "less critic"). Most Policy modules are based on Damian Conway's book Perl Best Practices ( PBP ), but it's not limited to it. I run perlcritic (using typically severity 3) automatically on all the source code files, every time I run the unit tests and/or build a package, in order to get as soon as possible a valuable feedback after code changes. Since the ...

Programming: the first thing to learn

Many of us had courses, attended lectures and speeches on programming. Many of us read (even many) programming books, and regularly read articles and blogs about programming. Have you ever thought of what should have been the first thing to learn in programming? The usual "variables, operators, data structures, classes, templates, metaprogramming, ..." or something else? I've come to the conclusion that the most important thing, the first thing to learn, the one that if you're not familiar with you shouldn't even keep studying programming, is the answer to this question: "How can I verify my code works?" . If I was a teacher, right before writing my name on the blackboard (yes, this is how I like it to imagine it), I'd write this: "How can I verify my code works?". And I'll spend the entire lesson waiting for someone to come up with a reasonable solution. If nobody goes close to it, I'd assign it as an essay for the following lesson...