Perl Testing: A Developer's Notebook

Chapter 5. Testing Untestable Code

One of the precepts of good unit testing is to test individual pieces of code in isolation. Besides helping to ensure that your code works, this testing improves your design by decoupling unrelated modules and enforcing communication among well-defined and, hopefully, well-tested interfaces. It also makes debugging failed tests easier by reducing the number of failure points.

Testing in isolation is difficult, though. Most applications have some degree of interdependence between components, being the sum of individual pieces that don’t always make sense when isolated from the whole. An important pattern of behavior in testing is mocking : replacing untestable or hard-to-test code with code that looks like the real thing but makes it easier to test. Perl’s easygoing nature allows you to poke around in other people’s code in the middle of a program without too much trouble.

This chapter’s labs demonstrate how to change code—even if it doesn’t belong to you or if it merely touches what you really want to test—in the middle of your tests. Though fiddling with symbol tables and replacing variables and subroutines is very powerful, it is also dangerous. It’s too useful a tool not to consider, though. Here’s when, why, and how to do it safely.

Overriding Built-ins

No matter how nice it might be to believe otherwise, not all of the world is under your control. This is particularly true when dealing with Perl’s built-in operators and functions, which can wreak ...