Why Perl is Ideal for All of Your Automated Testing (2 of 4)

In this installment I will explain why Perl is the ideal language to automate your tests for any application at the unit level.
There’s been a lot of difference of opinion on what unit testing is supposed to be. I think this is a good discussion, but I don’t think it goes anywhere near addressing this point. Therefore, I shall define what unit testing is in my words, and that is the definition that we’ll use for this explanation. Unit testing, in my view, is testing at the simplest level–or unit–of an application code. This will be at the function level, at the class/object level, at the instruction-set level, etc. The unit test is a test that cannot be made any more atomic without being redundant on a dependency’s own testing.
In this scenario…

int add_two(int a, int b) {
  fprintf(stdout,"Adding %d and %dn",a,b);
  return (a + b);
int add_three(int a, int b, int c) {
  return add_two(add_two(a,b),c);

with unit-level testing you would create a unit test for both add_two() and add_three() individually, and not for fprintf(). (yeah, I know that is making it very obvious, but some folks may need the verbosity)
Okay, so now that we understand unit testing, the question remains… why Perl? What an excellent question! So many people know how Perl is used for web applications and also for various other programs and scripts, but one thing you may not have known is that Perl also has an outstanding set of modules that make up an awesome testing framework. Check this out:
Perl Testing Reference Card
This is a reference card put out by the Perl QA folks, and it’s been passed around a lot. I like it. Clearly there has been a lot of emphasis put on automated testing in Perl (one of the reasons why it’ll work).
Perl is portable. There is a stable and usable Perl for every operating system I’ve used, and most that I’ve heard of, and most Perl scripts seem to be mostly portable. The only time one seems to be non-portable is when the use of an external library (via XS or other means) is found.
Perl can make use of other non-Perl languages. Anybody here program anything in JavaScript? Well, there’s Test::JavaScript for your testing needs. There’s even JavaScript modules if you want to directly interact with JavaScript through SpiderMonkey. What about Java? Inline::Java will take care of those folks. Python? There are Python libraries. C? Inline::C. Ruby? Inline::Ruby. Anything win32 could make use of the Win32::API module.
Perl focuses a lot of time and energy on testing. I think we could all make use of this effort. I also think most of us (all of us if we’re being honest with ourselves) could agree that we all could use more automated tests.
Will you be able to shoot holes in my argument? Sure. Is the word “ideal” for all of those situations a bit of a stretch? You caught me. But if this gets you thinking about automated testing, and gets you thinking about Perl, then my job here is done. See you tomorrow folks, when we’ll talk about integration and functional testing.

6 Replies to “Why Perl is Ideal for All of Your Automated Testing (2 of 4)”

  1. Python is just as portable as Perl – maybe moreso as it is also on PDA’s and mobile phones.
    Python can make use of other languages such as C, C++, Fortran;can call shared library functions/DLL’s has implementations on the Java VM, and in .NET; has tools to convert Python to javascript to allow AJAX applications to have both server-side and client-side code originally written in Python.
    The Python community focuses a lot on maintainable and testable code. There is much less spaghetti Python code out there and much less emphasis on code obfuscation within the community.
    Python includes several ‘Junit type’ testing tools as well as a more pythonic Doctest module.
    I agree that the most important hurdle is getting coders to do more testing. i disagree with your premise that Perl is the best too for the job 😉
    – Paddy.

  2. In order to have effective testing you want to make sure all developers on the project are extremely comfortable with the tools. Any test framework will have some learning curve, though if the developers also have to learn a new language it will significantly steepen that curve.
    If Perl is already an essential language to know in your team then it may be a good fit for testing your code written in other languages as well. However if your team is not already comfortable with Perl they will probably not write as many or as good of tests as if the test framework used a language they are already familiar with. A lot of developers still don’t view tests as an “essential” part of development, so while they might be willing to dive in and learn Perl if it’s part of the main development, if it’s only used for testing they’ll probably just do less testing rather than invest the time in learning Perl.
    Paddy also mentioned the Python doctest module which is a good example of how language-specific tools can have major advantages. I don’t know of any other tools quite like doctest, and it’s one of my favorite ways of writing tests. With the module you can simple paste snippets from the Python interactive shell into your API documentation and doctest will extract and run these snippets as tests. It’s a great way to write both documentation and tests simultaneously.
    So, a short example based on your code above:
    def add_two(a, b):
    ”’Adds two numbers and prints the
    >>> add_two(1, 2)
    Adding 1 and 2
    Adding incompatible types produces
    an error:
    >>> add_two(1, None)
    Traceback (most recent call last):

    TypeError: int argument required
    print “Adding %d and %d” % (a,b)
    return a + b
    So, while I’m sure Perl has some good testing tools, before using it to test your non-Perl code be sure to compare it to the tools available for the language and make sure that your team will be comfortable with the tool you choose.

  3. Okay, I’m sorry, but I never thought the topic is why Perl is better than Python. I’m talking about Perl being good for the specific task of automated testing. Never have I said that Python was less anything than Perl.
    If you would prefer to comment on Python’s aptitude for automated testing, I have no problem with that. Please stay on topic though. This is a post about automated testing and how Perl is good for it, not a post on how Perl is better or Python is better.

  4. Well, in your first sentence you state “I will explain why Perl is **the** ideal language to automate your tests for any application” (emphasis mine). My comment was not so much about Perl vs. Python in general, but that you should consider what tools are available in the language your developers are already using since while Perl may have good tools for testing, if your developers don’t know Perl you’ll be creating an additional hurdle to getting them to write tests. When I worked in Java I used Jython occasionally to test out some code, or I used the Python command line to test an XML-RPC service I was writing in Java. For these simple one-time tests I found Python to be a good tool, but I didn’t make them part of the automated test suite since other developers would need to work on it who did not know Python. When considering Perl as an automated testing tool you’ll need to make similar considerations. While your developers that know Perl may write really good tests with it, if it makes it more difficult for other developers to write tests then it’s probably not the “ideal” choice.

  5. Sorry. I was referring more to the tone of other commenters 🙂
    I totally agree that folks should consider all available options when deciding how they want to do automated testing. I did elude that my use of the word “ideal” was a bit of a stretch there. Titles are intended to draw readers, and I think I achieved that. Either way, we’re talking about automated testing. Maybe talking to it will translate into more of it.

  6. I will concede that my biases against Perl have more to do with being old and set in my ways as a C programmer than with any shortcomings other than its cryptic nature and unnecessarily picky syntax. (My biases against MFC are stronger and more justified, as are any and all biases against Micros***.) Prior to using PHP, when all my web development was either HTML or CGI, I used Perl, on systems where I had no telnet access, solely as a way to bootstrap my way into the shell to run the C compiler!
    However, the power of regular expressions does somewhat compensate for their less-than-intuitive (to my eye) structure, and the reason search engines, even Google, are not better than they are is that their logic has been dumbed down nearly to the LCD. In direct contrast, the long-defunct WWWW (WorldWide Web Worm) of yore supported Perl regular expressions before I had any inkling what preg expressions were!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.