Perl Testing: A Developer’s Notebook

I just finished reading Perl Testing: A Developer’s Notebook by Ian Langworth and chromatic (yes, one of the authors identifies himself/herself as “chromatic,” presumably for privacy concerns). All in all, the book was eye opening in understanding the world of testing in Perl. I develop Perl code at work in a culture that does not focus on unit testing, but, equipped with the things that I learned from this book, I am now even more adamant that I will be creating unit tests for all of my future Perl code.

Unlike Python’s core testing library, unittest, which is focused on objects and test methods, Perl’s core testing libraries, Test::Simple and Test::More, are focused on procedural style testing. As a consequence of being procedural, Perl test code has a style that reads very differently from a Python test case, and it is this style that was so eye opening about the Perl Testing book. The style difference isn’t a bad thing, it just requires some mental adjustment shifting.

Perl Testing is written in a no-nonsense manner that jumps straight to a solution for how to solve some hard problems when testing Perl. Personally, I think that the book’s style makes the material such a useful resource when considering how to test a problem. The Perl community likes to say TIMTOWTDI, which means “There is more than one way to do it,” but sometimes there are too many ways to do something. Langworth and chromatic provide lots of solid examples of how to test things so that you, as a future Perl test code author, will not have to recreate the logic necessary to test some really challenging code.

The book isn’t perfect, but the overall quality of the material, and the incredibly helpful libraries that it introduces, makes Perl Testing: A Developer’s Notebook a valuable resource for any Perl developer who wants to test his code (which should be every Perl developer).

Test Driven Development woes

I just finished reading Kent Beck’s Test-Driven Development, and, while I enjoyed the examples in the first half of the book, I’m disappointed about the lack of discussion on dealing with “legacy” code.

In my short amount of time using Test-Driven Development (TDD), I have seen that it can be a great, confidence building tool; and it has enabled the Entertainer devs to iron out some major issues in the code base (e.g., video thumbnailing was done entirely by Paul by following the TDD principles). However, I have struggled with retroactively applying TDD and unit testing to preexisting code.

I have literally lost sleep thinking about how to isolate tests and break coupling of existing classes. My hope was that Beck’s book would provide some answers. Instead, I got “There is a whole book (or books) to be written about switching to TDD when you have lots of code. What follows is necessarily only a teaser.” His “teaser” basically stated that there is a Catch-22 of “refactoring would result in errors because there aren’t tests, and tests can’t be written because the code isn’t refactored for it” (paraphrased). And his advice is essentially to try your best to break it. The entire subject gets about a page in the book. Thanks Kent.

Would I recommend reading Beck’s Test-Driven Development? Sure. It’s a good introductory read to understanding the core principles of “test-first” unit testing. The first half of the book offers some great, relatively simple examples that most developers should have no trouble following. The second half does disappoint, however, as it seems more like half-baked refactoring advice instead of tackling really challenging problems that could be addressed (like what to do with preexisting code or GUIs).

I’ll be reading Fowler and Beck’s Refactoring: Improving the Design of Existing Code next to see if I can get some answers to the questions that I desperately want; even if that advice is set outside of the unit testing/TDD mentality.

>>> print “Hello World!”

This is my first blog post, and since it’s my first post, I’d like to explain the purpose of my blog. My great adventure into the blogosphere will probably have a distinctive slant toward all things Python. I intend to journal my experience with my involvement on the Entertainer Media Center project. Entertainer is written in Python, a dynamically typed language that I’ve spent some time with over the last couple of months.

As someone who uses Perl for development in his day job, my brief impression of Python is amazement at its elegance and readability. Python has already showed me how easy stuff like unit testing and Test Driven Development can be. But that’s a subject for another post. I don’t want to drone on already, so I’ll stop here.

Thanks for reading.