Giacomo Vacca

Developers with a background in Ruby on Rails and PHP are familiar with the concepts of mocking objects and setting expectations on them. The good news is that these powerful techniques for unit testing are available for Perl as well. Should I add you can find them on CPAN ? Before an example though, just a simple explanation about the topic. Unit testing “is a method by which individual units of source code are tested to determine if they are fit for use” (Wikipedia). It’s a common practice to perform unit testing in isolation ; in other words you focus testing on the source code, limiting as much as possible the interaction across modules or systems. It’s almost always practically impossible to test a class without instantiating other classes on which it depends or interacts. What can be done is mocking objects : creating “empty objects” that emulate the external behaviour of real objects. They must be able to “fool” the class under test and allow the creation of an exhaustive set ...

Browsing StackOverflow on perl-related topics, I have two main considerations: 1. Answers are typically very good, concise and useful 2. Questions are submitted with code that doesn't have 'warnings' enabled I'd say that a considerable portion of the questions submitted would not be posted, or would be less generic, if authors used 'use warnings;' in their code. Then add a pinch of the great perl critic , and possibly only half of the questions would really be submitted. If you're using perl, or plan to use it, I strongly recommend to: 1. Always set 'use warnings;' 2. Always submit your code to perl critic (and keep a copy of Perl Best Practices handy). 3. First create the tests, then write the code. That's the only reasonable way (unless you're working on a one-liner for a quick admin task). TDD is your friend . See more on Perl Critic here .

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...