Why is testing important? ( なぜテストは重要ですか ? )

... or not. What if, instead of "All tests successful", you see a series of cryptic messages:

... どうだろう. どうなりますか, 代わりに "すべてのテストが成功した" の, あなた見るなら 一連の不可解なメッセージを:

% sudo make test

/usr/bin/perl Makefile.PL --config=-target,skiptest

--installdeps=Term::Size,0.01

*** Installing dependencies...

*** Installing Term::Size...

Can't bless non-reference value at lib/CPANPLUS/Internals/Module.pm

line 239.

Compilation failed in require at Makefile.PL line 20.

make: *** [installdeps] Error 255

An experienced Perl user will probably take the following steps:

経験がある Perl ユーザはおそらくとります 次のステップを:

・Look at lib/CPANPLUS/Internals/Module.pm and see if it's a trivial mistake. Unfortunately, it is not.

・Search README for the project's mailing list address. Discovering that it's hosted in SourceForge, check Geocrawler (or any search engine) for existing bug reports and discussions. Unfortunately, there are none.

・Copy-and-paste the error message into a bug-reporting email to the mailing list, including your operating system name and version, perl version, and wait for a fix.

・よく見ます lib/CPANPLUS/Intarnals/Module.pm を それと 見ます それがささいな間違いであるかどうかを. あいにく, そうではない.

・検索します README を プロジェクトのメーリングリストアドレスのために. 発見したら それがホストされていることを SourceForge で, チェックします Geocrawler ( または任意の検索エンジンで ) を 既存のバグリポートや議論のために. あいにく, 何もない.

・コピー and ペーストして エラーメッセージを バグリポーティング email の中に メーリングリストへの, 含めます あなたのオペレーティングシステム名とバージョン, perl バージョン, それと待ちます 修正を.

Apparently, the above is exactly what Jorrit Waalboer (the bug's original reporter) did when he ran into this trouble.

見たところ, 上記は まさに Jorrit Waalboer ( バグのオリジナルのリポーター ) が遭遇したときのものです このトラブルに.

However, there are a number of problems with the procedure above. It might be thwarted at every step:

しかしながら, 多くの問題があります 上記手順には. それは阻まれるかもしれません すべてのステップで:

・What if Jorrit had been less experienced, and unaware of this bug-reporting procedure?

・どうなりますか Jorrit が 経験が不足している, それと 知らなかったら このバグリポートの手順を ?

・What if he decided to kluge around it by commenting out line 239, instead of taking the laborious copy-and-paste path to report it?

・どうなりますか 彼がクルージ (その場しのぎの解決) すると決めたら 周囲をコメントアウトすることによって 239 行目の, とる代わりに 面倒なコピー and ペーストをとおってリポートすることを ?

・CPANPLUS has a mailing list; other modules might not. Worse, they may not even have a working contact address -- maybe the author is on vacation. (Note that this problem is somewhat alleviated by the CPAN Bug Tracking service at http://rt.cpan.org/)

・CPANPLUS はメーリングリストを持っています; 他のモジュールはそうでないかもしれません. さらに悪いことに, 彼らは動いている連絡先アドレスでさえもっていない -- あるいは 著者は休暇中かもしれません. ( 留意してください この問題はいくらか緩和されます CPAN Bug Tracking service によって http://rt.cpan.org/ の )

・He might not have the sense to provide adequate debug-related data, and simply wrote "CPANPLUS didn't work! It can't install!#!@#@#!" in red-colored blinking HTML email, wasting bandwidth and causing developers to ignore his mail completely.

・彼はもっていないかもしれません 提供するセンスを 適切なデバッグ関連のデータを, それで単に書きます "CPANPLUS は動きません ! それはインストールできません !#!@#@#!" と 赤色で点滅する HTML email で, 帯域幅を無駄にして 開発者に無視させることになる 彼の mail を完全に.

・Even after a fix is made available, and posted as a patch on the mailing list, other people about to install CPANPLUS 0.03 still have no way to find out about it beforehand. Thus, when the same problem occurs again, they may forget to search in the archives, resulting in duplicate bug reports, or (worse) more dissatisfied users.

・修正が利用可能になり, 投稿された後だったとしても パッチとして メーリングリストに, 他の人々は CPANPLUS 0.03 をインストールしようとしている まだ方法をもっていません 見つけ出す それについて 前もって. したがって, 同じ問題が起こったとき 再び, 彼らは検索することを忘れるかもしれません アーカイブで, 結果として 重複します バグリポートが, または ( さらに悪いことに ) より不満になります ユーザが.

・Actually, we had not mentioned the very likely scenario: what if Jorrit didn't run make test at all? If so, the developers will have no way to know that this bug has ever happened.

・実際のところ, 私たちは言及していませんでした とても可能性が高いシナリオを: Jorrit が実行していなかったとしたらどうなるでしょう make test を まったく ? もしそうなら, 開発者は知る方法をもっていません このバグがこれまでに起こったことを.

・Finally, while CPANPLUS (like most CPAN modules) includes a regression test suite, some modules may omit their tests altogether. Users may not feel comfortable to mail the author to request a test script to accompany the distribution; consequently, bugs will surface in harder-to-detect ways, and may never get fixed.

・最後に, CPANPLUS は ( ほとんどの CPAN モジュールのように ) 含んでいますが 回帰テストスイートを, いくつかのモジュールは 省略するかもしれません それらのテストを 全部. ユーザは快適に感じないかもしれません 著者に mail することが リクエストするために test スクリプトを ディストリビューションに伴う; 従って, バグは表面化します検出が困難な方法で, それと 決して修正されることはないでしょう.

As you can see, both authors and users can certainly benefit a lot from an improved test reporting system -- one that simplifies the process of reporting a failed (or successful) installation, and lets users check for existing reports before downloading a module.

あなたが見たように, 双方は 著者とユーザの 確実に恩恵を受けられます 多くの 改善されたテストリポーティングシステムから -- それは プロセスを簡略化します インストール失敗 ( または成功 ) のリポーティングの, それと ユーザがチェックできるようにします 既存のリポートを モジュールのダウンロードの前に.

Such a system already exists; it's called CPAN Testers

そのようなシステムは すでに存在しています; それは呼ばれています CPAN Testers と

NEXT

次回は、About CPAN Testers の「 WhatIsCPANTesters 」を確認します。


参考情報は書籍「 続・初めての Perl 改訂版 」, 「 Effective Perl 第 2 版 」を中心に perldoc, Wikipedia および各 Web サイト。それと詳しい先輩。

目次 - Perl Index