If you release modules on CPAN, sooner or later you will get some FAIL and UNKNOWN reports. Even if your module is perfect (which it isn't), sometimes something will go wrong.

This post/thread tries to list common errors and error types that can break cpantesting.

In addition to looking at your test scripts results, also look for obvious signs that something on the testers system went wrong.

• Can't write to MakeMaker.tmp: No space left on device at /smoker/5.14.0/perl/lib/ExtUtils/MakeMaker.pm line 1020.
• Can't locate GD/Group.pm in @INC The report also says that GD 2.41 is installed. Either i messed up minimum requirement of installed GD or the installation is missing some files.
• No package 'libavformat' found on x64 linux. Even if the lib is installed correctly, MakeMaker sometimes doesn't find it, which is clearly a MM bug. There is a workaround: 944371
• make: *** No targets specified and no makefile found. Stop. and No requirements found. Something went wrong during the unpacking or Makefile.PL stage that didn't leave any trace in STDERR. Strange...
• Don't expect any network tests to actually work. Especially not when the tests requires you to run a server port (which might already be in use), connect to a local service (which might not be installed/running) or connect to the internet (which might be firewalled). When testing a network protocol handler, try testing it through STDIN/STDOUT pipes.
• If you involve external modules like XML parsers, write a separate test for them. Especially modules that use external libraries (libexpat, libavformat, ...) are notorious for breaking (or not working in the first place... happened to me with pre-compiled ActivePerl modules).
• Don't assume you can open a window, just because the appropriate libs are installed. Installing Tk remotely should be possible without X11-Forwarding.
• Overcomplicated, long running tests might run into a timeout or the modules might be blocked for hogging server resources. The only people who need to run Perl::Critic tests or test-encode 10 Gigs of data for a burn-in test are the developers of that module, not the testers and users.
• A very common mistake in tests: Do some math and then equal-compare the result with a predefined value. Ooops, differences in floating point precission will make your tests FAIL. So, if the program calculates "10/7", use something like "abs($x - 1.428) < 0.001" as test criterium.

Please add your own favourite errors in the comments.