Data::Dumper is like a carpenter's level. You may catch a glimpse of in use on a job site, but you'll rarely see it in the finished product unless someone got sloppy. I'm working with a team that's been doing Test-Driven Development (TDD) in Perl for a while, using Data::Dumper in an on-the-job-site way I haven't seen described before. In the hope that it turns on lightbulb in someone's dim corner, here's roughly how it works:

When writing a new package using TDD, the idea is to posit a few tests that make assertions about how you want the world to be, and then write the code to make those tests pass. Then more tests, then more code, and so on, with the test file and the package growing in parallel. The tests tend to be black box, but sometimes it helps to peek, particularly for sanity checks.

Our first common use of Data::Dumper is for quick sanity checks as we're bootstrapping tests. At the beginning of a .t file, I might create an instance of the package being developed, and then do a quick dump of it as a sanity check, followed by a test.

  my $thing = Thing->new(model => $model);
  print Dumper $thing;
  ok( $thing->model, $model );
[download]

This is a kind of quick lifting of the veil, making an otherwise black box test white for a brief moment. This also useful when I'm building a larger assemblage, and want a quick verification that I've gotten it right. Once I'm satisfied, the Dumper call goes away. If you hadn't been looking over my shoulder, you'd have missed it, and would have no idea of how useful it had been for that one, brief moment.

Our other common way of using Data::Dumper hinges on the little-known, not exactly well-documented, but not at all surprising fact that Test::ok() returns 0 or 1, reflecting the failure or success of the test. This lets us write

  $thing->do_something_interesting();
  # the thing's model shouldn't have changed
  ok( $thing->model, $model ) or print Dumper $thing;
[download]

which will both report a failed test and give us diagnostic info to look at. A simple technique, but one that's paid off in time saved when we're taking small, but daring steps, and want rapid feedback that goes beyond "yup, it's broke".

So there it is. The next time you're writing tests cases, try keeping Data::Dumper (or perhaps the new Data::Dumper::Simple) within reach.

And if you're in Silicon Valley, know network management, and want to do XP/TDD in Perl, AirWave is hiring. /msg me for details.