答え

Perlでは伝統的にテスト用モジュールパッケージが使用されており、Test::Simple、Test::More、さらにはTest::Class、Test::Mostのような複雑なフレームワークがあります。基本的なモジュールはTest::Moreで、これは豊富な機能セットを提供します: 等価性のチェック、構造の比較、例外のテストなど。

人気のあるモジュールの分類:

Test::Simple — 非常にシンプルで基本的なテスト用;
Test::More — 大多数のプロジェクトのデファクトスタンダード;
Test::Exception, Test::Deep, Test::Warn — 追加の側面（例外、ネストされた構造、警告）をチェックするため;
Test::Class, Test::Class::Moose — オブジェクト指向のアプローチ。

Test::Moreを使ったテストの例:

use Test::More tests => 2;

is(2 + 2, 4, '合計が正しい');
like('foo_bar', qr/foo/, 'fooがある');

ベストプラクティス:

すべての公開モジュールにはt/-ディレクトリに自動テストが必要。
テストデータと本番コードを混在させない。
単体テスト、統合テスト、時にはプロパティベースのテストを適用する。

トリッキーな質問

Test::*モジュールを使用せず、単にdie/print構文を使ってPerlで自分のテストを書くことはできますか？そのようなアプローチにはどんなリスクがありますか？

答え: 形式的には可能ですが、printやdieを使用して独自の「テスト」を書くことができます。しかし、その場合正しい自動化のアプローチが形成されず、TAP/CPAN統合がサポートされず、レポートの作成や多数のテストの分析が困難になり、テスト基盤のスケーリングや保守が難しくなります。

失敗したテストの例:

print '掛け算が正しい
' if multi(2,3) == 6;
die 'FAIL' if multi(2,0) != 0;

トピックに関する細部を知らないことによる実際のエラーの例

物語

古いプロジェクトでテストは手動でdieとprintを介して書かれていました。CPANモジュールのビルドを自動的に統合することができず、スクリプトは明確なステータスを返さなかったため、テストの失敗がリリースに流入しました。

物語

Test::SimpleとTest::Moreの使用をTAP（Test Anything Protocol）の構造を考慮せずに混合しようとした結果、出力が破損し、自動テストシステムが無効になってしまいました。テストインフラストラクチャの再設計が必要でした。

物語

Test::Exceptionのカバレッジが不十分だったため、入力データ処理のエラーがいくつか見逃されました: 一つのモジュールが例外を正しくスローせず、テスト中にそれが発見されず、バグが本番環境に入りました。

Perlにおけるテストの仕組み: どのような組み込みおよびサードパーティのテストモジュールが存在し、それぞれの違いは何か、またPerlプロジェクトで広く使われているテストのベストプラクティスはどれか？

答え

トリッキーな質問

トピックに関する細部を知らないことによる実際のエラーの例