コーディングと単体テストはDRY原則に違反していますか

ドライ原則は次のように述べています：

「すべての知識は、システム内で単一の明確な権威ある表現を持つ必要があります。」

ただし、コードのテストを作成するときは、システムの予想される動作を2回記述します（コードで1回、テストで1回）。私は両方の説明が異なる視点からのものであることを知っていますが、根本的なアイデアの多くを共有しています。

これについて何か考えはありますか？

一般に、ユニットテストとDRYの原則はどちらも優れたアイデアであり、可能な限りそれらを適用しようとしています。この質問はもっと哲学的なレベルのものですが、誰かもこれについて考えているのではないかと思いました。

あなたは不完全な前提で動作しています。

コードは期待される動作の説明ではなく、要件とテストケースのみです。それでも、要件とテストは動作の2つの側面を定義します。要件はソフトウェアシステム全体の特性と機能を定義し、テストは期待される結果がどうあるべきかを定義し、要件と照合します。コードは、これらの要件とシステムのアーキテクチャの開発者による解釈です。

いいえ、単体テストは機能を再現しないため、DRYの原則に違反していません。機能（re：責任）が適切に動作することを確認するだけです。単体テストの場合、テストしているメソッドは引き続き維持されauthoritative representationます。テストコードは、製品版のメソッドを実装するコードと非常に似ているかもしれませんが、独自の明確な目的があります（テストをアサートするため）。

やや。それらがあまりに類似している場合、はい、それは悪いことです。テストは、テストするコードと同じ方法でコーディングしないでください。したがって、（1）期待と（2）実装を定義する必要があります。

それは複式簿記に似ていると思いたいです。会計システムは常に少なくとも2つのエントリ（借方と貸方）を作成します。これはエラーチェック方法です。1日の終わりに、借方と貸方のバランスを取る必要があります。そうしないと、エラーが発生します。何らかの形の冗長性がないと、エラー検出システムを構築できません。

たとえば、CRCについて考えます。CRCバイトは冗長性の一種です。信号の小さなエラーを検出するのに十分です。同様に、オーディオCDには多くの冗長な情報が含まれているため、傷がついても完全に再生されます。これはDRYの原則に違反していますか？おそらく、それが信頼性を得る方法です。

それを見る別の方法もあります：

あなたのテストは信頼できる答えです。テストするコードは、コードモンキーであるあなたによって自動生成されます。ユニットテストに基づいてコードを自動生成できる場合（データベーススキーマに基づいてデータアクセスレイヤーを自動生成する場合など）、DRYの原則（または少なくともOAOOの原則ではない）に違反することはありません。

ただし、コードのテストを作成するときは、システムの予想される動作を2回記述します（コードで1回、テストで1回）。

結構です。コードは、予想される動作の説明ではなく、その実装です。エラーが含まれる可能性があるため、テストが必要です。

かなり単純なアルゴリズムや抽象化を実装することも、それを説明するよりもはるかにトリッキーです。きちんとしたプログラマーであれば、バイナリ検索のしくみを数文で説明できますが、ジョンベントレーは、彼の実験では、コースに参加している経験豊富なプログラマーの70％以上が正しく実装できなかったと報告しています。

これがユニットテストが必要な理由です。同じ結果を達成するために2倍の仕事をすることを好む人は誰もいませんが、この慣行を策定して伝道したすべての開発者は、自分の苦労して得た経験から、それらを必要とすることに気付きました。彼らはソフトウェアをできるだけ早く開発したいと考えた賢い人たちでした-そのため、開発プロセスからすべての重複した無駄な雑用を取り除く必要があります。単体テストは重複したジョブではありません。