[解決済み】ユニットテストについて語るときの「DAMP not DRY」の意味とは？

質問

ある人が、ユニットテスト（nUnit、jUnit、xUnitなど）には

ダンプ ではなく DRY

(例: ユニットテストには、quot;ドライコードではなく、quot;ダンプコードを含める必要があります)

何を言っているのだろう？

どのように解決するのか？

矛盾ではなく、バランスである

DAMPとDRYは矛盾するものではなく、むしろコードの2つの異なる側面のバランスをとるものです。 保守性 . ここでは、メンテナンス可能なコード（変更が容易なコード）が究極の目標です。

ダンプ (Descriptive And Meaningful Phrases)が推進する。 読みやすさ を使用します。

コードをメンテナンスするには、まずコードを理解する必要があります。理解するためには、コードを読まなければなりません。あなたが以下のようなことにどれだけの時間を費やしているか、ちょっと考えてみてください。 読む コードになります。かなりの量です。 DAMPは、コードを読んで理解するのに必要な時間を短縮することで、保守性を向上させます。

<強い DRY (繰り返しにならないように) を推進します。 直交性 のコードです。

重複を排除することで、システム内のすべてのコンセプトが、コード内で単一の権威ある表現を持つようになります。1つのビジネス・コンセプトを変更すると、コードも1つだけ変更されます。 DRYは、システムの変更しなければならない部分だけに変更（リスク）を隔離することで、保守性を向上させます。

では、なぜテストでは重複が許容されやすいのでしょうか？

テストは、入力値やセットアップコードが少し異なるだけで、同じものを何度もテストしているため、本質的に重複を含んでいることがよくあります。しかし、実稼働コードとは異なり、この重複は通常、単一のテストフィクスチャ/ファイル内のシナリオにのみ限定されます。このため、重複は最小限かつ明白であり、他のタイプの重複と比較して、プロジェクトに与えるリスクは低くなります。

さらに、このような重複を排除することで、テストの可読性が低下します。これまで各テストで重複していた詳細が、どこか新しいメソッドやクラスに隠されてしまうのです。テストの全体像を把握するためには、これらの断片をすべて精神的に組み立て直さなければならなくなります。

したがって、テストコードの重複は、リスクが少なく、可読性を高めることが多いので、許容範囲と考えるのは簡単です。

原則としては、本番コードではDRYを、テストコードではDAMPを支持します。どちらも同じように重要ですが、ちょっとした知恵で、バランスを有利にすることができます。