If you project depends on a interaction with a web server, especially a remote one, you have some challenges with testing that portion. Even if you can get it working for you, when you distribute your code, someone else might not be able to reach your server for testing. Instead of relying on an external server, you can use a local server that you write especially for your test suite. Continue reading “Make disposable web servers for testing”
Category: testing
Group tests by their task with Test::More’s subtest()
In the earlier Item, Understand the Test Anywhere Protocal (TAP), you saw the very basics of that simple, line-oriented test report. You ran a single test and it output a single line to denote the status of the test, and possibly some diagnostic information. The TAP, however, didn’t organize any of the tests for you. Continue reading “Group tests by their task with Test::More’s subtest()”
Hide low-level details behind an interface
Perl 5.16 makes the Perl special variable, $$, writeable, but with some magic. That’s the variable that holds the process ID. Why would you ever want to do that? There’s not much to write about with this new feature, but there’s plenty to write against it since it introduces more magic (see commit 9cdac2 on June 13, 2011). Continue reading “Hide low-level details behind an interface”
Understand the Test Anything Protocol
The Test Anything Protocol, or just TAP, is the formalization of Perl 5’s test structure from the Test::Harness module. Either Andreas König or Tim Bunce (they don’t remember which one of them did it) created the module, but they can’t remember who did what or when. The Changes file for the Test-Harness starts in seriousness in 2006, around the time that people started working on the next generation of Perl’s testing backend, despite it existing for several years before that. Now TAP is semi-formalized (and IETF RFC is in the works) and has it’s own website at testanything.org. Continue reading “Understand the Test Anything Protocol”
Pass the empty subclass test
Is your object-oriented module subclassable? Do you know that from testing or are you just guessing? Setting aside other Perl programmers reaching into your package and redefining your subroutines, there are some basic things you can do to ensure that you’ve made life unhard for the people you want to extend your classes. Continue reading “Pass the empty subclass test”
Use Test::More as you experiment
When you’re trying something new, write small programs to test the idea or the new feature. This way, you isolate what you’re doing from the rest of the big application where you might want to use the idea. Some people try to insert the new features directly into the middle of their large programs, but then have problems separating the bugs from the rest of the application with the new thing they want to add. Continue reading “Use Test::More as you experiment”