← Back to Knowledge Base← Previous questionNext question →
ProgrammingPerl developer, testing engineer

How does testing work in Perl: what built-in and third-party testing modules exist, how do they differ, and what testing practices are widely used in Perl projects?

Pass interviews with Hintsage AI assistant

Answer

In Perl, a package of testing modules is traditionally used: Test::Simple, Test::More, as well as comprehensive frameworks like Test::Class, Test::Most. The baseline is Test::More — it provides a rich set of functions: equality checks, structure comparisons, exception testing, etc.

Classification of popular modules:

  • Test::Simple — for very simple, initial tests;
  • Test::More — the de facto standard for most projects;
  • Test::Exception, Test::Deep, Test::Warn — for checking additional aspects (exceptions, nested structures, warnings);
  • Test::Class, Test::Class::Moose — object-oriented approaches.

Example test with Test::More:

use Test::More tests => 2;

is(2 + 2, 4, 'Sum works');
like('foo_bar', qr/foo/, 'Has foo');

Best practices:

  • All public modules should have automated tests in the t/-directory.
  • Do not mix test data with production code.
  • Apply unit, integration, and sometimes property-based tests.

Tricky question

Can you write your tests in Perl without using Test::* modules, just using die/print constructs? What are the risks of such an approach?

Answer: Formally yes — you can write your own "tests" using print and die for outputting results. However, in this case, a proper approach to automation is not formed: TAP/CPAN integrations are not supported, it becomes difficult to create reports and analyze multiple tests, scaling and maintaining the test base becomes problematic.

Example of a failed test:

print 'Multiplication ok
' if multi(2,3) == 6;
die 'FAIL' if multi(2,0) != 0;

Examples of real errors due to lack of knowledge on the topic

Story

In an old project, tests were written "manually" using die and print. It was impossible to integrate CPAN module building automatically — scripts did not return clear statuses, causing testing errors to be missed in releases.

Story

The attempt to mix Test::Simple and Test::More without considering the TAP (Test Anything Protocol) structure led to output violations in the automated testing system. A complete overhaul of the testing infrastructure was required.

Story

The lack of good testing coverage by Test::Exception resulted in missing several input data processing errors: one of the modules incorrectly threw exceptions, which was not detected during testing, and the bug ended up in production.