Perl Testing: A Developer's Notebook

Preface

Is there any sexier topic in software development than software testing, at least besides game programming, 3D graphics, audio, high-performance clustering, cool web sites, and so on?

Okay, so software testing is low on the list. That’s unfortunate, because good software testing can increase your productivity, improve your designs, raise your quality, ease your maintenance burdens, and help to satisfy your customers, coworkers, and managers. It’s no surprise that the agile development techniques place such an emphasis on automated software testing—when it clicks for you and you understand it, you’ll wonder how you ever wrote software without it.

Perl has a bit of a reputation for being hackish and unserious. It’s certainly good for doing quick and dirty jobs quickly and dirtily. However, if you approach it with discipline, you’ll find that it’s suitable for big, serious projects. You probably already know this. You may not know how to apply the discipline, though. That’s where this book can help.

Perl has a strong history of automated tests. The earliest release of Perl 1.0 the authors know of included a comprehensive test suite. It’s only improved from there. The CPAN, a huge archive of freely available and reusable Perl code, exerts strong social pressure on contributors to write and maintain good test suites for their code. It also includes dozens of useful testing modules to make testing possible, or even easy.

Of course, your main job probably isn’t all Perl all the time. It may be just one of a handful of good tools you use. That’s fine. Learning how Perl’s test tools work and how to put them together to solve all sorts of previously intractable problems can make you a better programmer in general. Besides, it’s easy to use the Perl tools described here (and others that the future will bring) to handle all sorts of testing problems you encounter, even in other languages.

You don’t have to be a die-hard free and open source software developer who lives, breathes, and dreams Perl to use this book. You just have to want to do your job a little bit better.

What This Book Covers

The nine chapters of this book cover testing in Perl, starting as if you’ve never written a test before and ending by exploring some of the testing problems you’ll encounter in the real world. The authors expect you to know Perl already well enough to install and use Perl modules effectively in your own programs. You should have a decent understanding of Perl data structures and object-oriented programming. You need to have Perl newer than 5.6.0 installed, but the authors recommend at least Perl 5.6.1 and suggest that you consider upgrading to the latest version of the stable 5.8 series.

As for the chapters themselves, they discuss:

Writing basic tests

This chapter explains everything you need to start writing and running tests, including how to install testing modules, how to understand test results, and the basic test functions you’ll use in every test.

Improving your tests

This chapter builds on the previous chapter, demonstrating further test techniques and modules. Once you’re familiar with writing tests, you’ll encounter some common tasks and troubles. Here’s how to solve them.

Organizing and running tests well

This chapter shows how to take advantage of the basic testing tools to customize them for your environment and projects. In particular, it shows how to write your own testing libraries and harnesses.

Bundling tests and code into projects

Tests are just code, and all of the normal rules of disciplined coding apply. This chapter covers some of the issues you’ll face when you want to distribute your project, especially the issues of non-code portions of your project.

Testing hard-to-test code

Unit testing seems easy in theory, but complex projects have complex interactions that might seem impossibly untestable at first. This chapter claims otherwise. It recommends another way of thinking that allows you to substitute testable code—under your control—for code that otherwise looks untestable.

Testing databases and their data

Many programs interact with databases: relational, object, and flat file. While these normally seem outside the purview of what you can test from Perl, there are simple and effective techniques to verifying that your code does what it should. This chapter describes them.

Testing web sites and web projects

Layered applications, with display, logic, and data pieces, also seem difficult to test, especially if they’re not really layered after all. This chapter explores an alternative web application design strategy that makes projects easier to maintain and easier to test, too, as well as how to test them.

Unit testing

Traditional Perl testing differs from xUnit-style testing in the way it organizes, structures, and runs tests. You can have the best of both worlds, though. This chapter discusses a Perl testing framework that allows good code reuse within object-oriented project tests and yet works within the familiar Perl testing libraries.

Testing non-Perl and non-modules

There’s a whole world outside of Perl. Now that you know the power, flexibility, and ease of automated testing with Perl, this chapter suggests a few ways to use everything you’ve learned to test other projects written in other languages. Go forth and improve software quality worldwide.

Conventions Used in This Book

This books uses the following typographical conventions:

Italic

Used for new terms, URLs, email addresses, filenames, file extensions, pathnames, directories, and Unix utilities.

Constant width

Used for program listings, classes, methods, variables, keywords, and the output of commands.

Constant width bold

Used to show commands or other text that the user should type literally and to highlight sections of code examples.

Constant width italic

Used to show text that should be replaced with user-supplied values.

Handwriting font

Used for tips, suggestions, or general notes.

Using Code Examples

This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: "Perl Testing: A Developer’s Notebook, by Ian Langworth and chromatic. Copyright 2005 O’Reilly Media, Inc., 0-596-10092-2.”

If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at [e-mail].

Safari Enabled

When you see a Safari® Enabled icon on the cover of your favorite technology book, it means the book is available online through the O’Reilly Network Safari Bookshelf.

Safari offers a solution that’s better than e-books. It’s a virtual library that lets you easily search thousands of top technology books, cut and paste code samples, download chapters, and find quick answers when you need the most accurate, current information. Try it for free at http://safari.oreilly.com.

Comments and Questions

Please address comments and questions concerning this book to the publisher:

O’Reilly Media, Inc.

1005 Gravenstein Highway North

Sebastopol, CA 95472

[phone] (in the United States or Canada)

[phone] (international or local)

[phone] (fax)

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at:

    http://www.oreilly.com/catalog/perltestingadn

To comment or ask technical questions about this book, send email to:

    [e-mail]

For more information about our books, conferences, Resource Centers, and the O’Reilly Network, see our web site at http://www.oreilly.com.

The Perl QA project has a web site and mailing list devoted to discussing and improving software testing and in Perl. See the web site at http://qa.perl.org/ for information on joining the list as well as links to other testing modules, related projects, and articles and presentations on Perl and testing.

Acknowledgments

The authors thank their editor, Allison Randal, for finding the right format for this book, for taking care of messy little details, and for weighing in with editorial advice when necessary. The authors also thank everyone in O’Reilly’s production, marketing, tools, and PR groups who put this book in the hands of people who need it.

The authors also thank a bevy of technical reviewers for thoughtful suggestions, without which the book would be much poorer. In alphabetical order, they are David Adler, Ann Barcomb, Tony Bowden, Shawn Boyette, Jim Brandt, Mike Burns, Ben Evans, Shlomi Fish, Adrian Howard, Paul Johnson, James Keenan, Pete Krawczyk, Christopher Laco, Andy Lester, Pete Markowsky, Tom McTighe, Steve Peters, Curtis Poe, Steven Schubiger, Michael Schwern, Ricardo Signes, Brett Warden, and Geoffrey Young. Any remaining errors are the fault of the authors, or perhaps space aliens.

Finally, the authors thank everyone whose work has gone into the testing strategies and modules described here. Everyone’s better for it.

Ian Langworth

I’d like to thank brian d foy for noticing my Perl testing quick-reference card and his initial suggestion to get the ball rolling.

Thanks to the terrific faculty and staff at the College of Computer and Information Science at Northeastern University—especially the CCIS Systems Group folks and their volunteer group, the Crew. They have provided me with an amazing community over the years, to which I owe so much. Special thanks goes to Professor Richard Rasala, who mentored me for three months in this project’s early stages.

Thanks goes to Andy for all of his help and to Allison for letting this happen. Allison also set me up with a brilliant coauthor, whose grasp of the language amazes me to no end. This book wouldn’t be nearly as good as it is without chromatic’s tremendous writing prowess.

Thanks to all of my great friends (too many to list here), my wonderful parents, and to Emily. These people have been wonderfully supportive and deserve an immense amount of credit for having to put up with me regularly.

chromatic

Thanks to Allison for suggesting I work on this book and to Ian for coming up with the idea and accepting a coauthor. Thanks to everyone at O’Reilly for a fantastic day job. Thanks also to my friends who celebrated when I did and commiserated when I complained, especially the U of P bunch and Mel, Esther, Kate, and Eva. Apologies and love go to my family and most of all to my parents, Floyd and Annette, who know full well that I learned about testing things very early. At least now it has some productive value.