EUnit を使用するには、次の 2 つの一般的なアプローチがあるようです。
- モジュールの最後にテスト自体を含める
- テストを別の「テスト」パスに追加します
特定のモジュールのエクスポートされた関数をテストすることにのみ関心があると仮定すると、一方のアプローチを他方よりも選択することに利点や慣例はありますか?
1 に答える
3
tl;dr: 通常は、ソースの一番下に置くことができます。インターリーブは常に最悪です。非常に多くのテストを作成して、テスト固有のコードの塊のための特別な場所が必要になるということは、時間を誤って投資したことを意味します。
分割すると、ソース ファイルが短くなり、場合によってはナビゲートしやすくなります。OTOH、ソースをナビゲートするのが難しいのは、通常、他のより深い問題の兆候です。
私は、Dialyzer とユーザーが私の本当のバグ ファインダーであり、純粋に機能的で副作用のないコードを除けば、比較的実用性のないテストであることに気付きました。純粋に機能的なコードの場合、テストは些細なものです。一度そのようなコードがチェックされると、誰も何度も何度もそれを再訪する必要がなくなります。そのような場合、私は通常、最後にテストを含めるので、戻ってもう一度見つけたい場合にそれらを失うことはありません. できるだけ多くのコードがこのタイプになるまで、意識的にリファクタリングを行っていますが、その努力に見合うだけの価値があると誰もが同意しているわけではありません。
コードの毛むくじゃらの部分は、特に typer と Dialyzer を使用して、自分自身に対して犯している最も重大な違反を見つける作業を行っていない場合は、副作用のビットです。現実世界のすべてのバグに共通しているのは、すべてのテストに合格しているということだけです。テストの作成に費やされた労力と、副作用のあるコードのバグとの間に相関関係が見つかったことはありません。実際のところ、アクター モデル プロトコルを正式にテストする方法は現時点ではありません。また、インタラクションは通常、残りのバグが存在する場所であり、既に慎重に検討したプロセス内に隠されているわけではありません。
これを具体的な観点から考えると、誰かが X 時間かけて適切に入力したシステムで作業するか、X 時間かけてテストを作成して実行したシステムで作業しますか? 私の投票はタイピングに行きます。テストが悪いと言っているのではありません。開発者の時間がかかり、純粋に機能的なコード以外では有用性が限られていると言っているのです。純粋に機能するコードのテストには、明確に識別可能な制限があり、些細で小さい傾向があるため、テストが適用されるモジュールの最下部に目立たないように配置できます。
于 2014-11-02T15:12:30.553 に答える