テスト駆動開発では、SOLIDに従う必要がありますか？

TDDの実務者から、TDDの利点の1つは開発者にSOLID原則（単一責任、オープンクローズ、Liskov置換、インターフェイス分離、依存関係反転）を強制することであると多くのことを聞きます。しかし、私にとっては、いくつかのテスト（主に単体テスト）を記述するだけで十分であり、SOLIDに従うことが重要です（したがって、テスト可能なアーキテクチャを作成します）。

TDDは、開発者に単体テストを書くよりも積極的にSOLIDをフォローするように強制しますか？

まず第一に、TDDはSOLIDコードの作成を厳密に強制しません。必要に応じて、TDDを実行し、1つの大きな混乱を作成できます。

もちろん、SOLIDの原則を知っていると役立ちます。そうしないと、多くの問題に対して適切な答えが得られず、ひどいテストを伴うひどいコードを書くことになってしまいます。

SOLID原則について既に知っている場合、TDDはそれらについて考え、積極的に使用することを奨励します。

とはいえ、必ずしもSOLIDのすべての文字をカバーしているわけではありませんが、少なくとも部分的にSOLIDコードを書くことを強く推奨し、促進します。

例えば：

1. 必要なものをモックできるように、分離したコードを記述する必要があります。これはDependency Inversion Principleをサポートしています。
2. テストをあまり変更する必要がないように、明確で短いテストを書く必要があります（そうしないと、コードノイズの大きなソースになる可能性があります）。これは、単一責任原則をサポートします。
3. これについては議論の余地があるかもしれませんが、インターフェイス分離の原則により、クラスはより軽いインターフェイスに依存してモックを理解しやすくします。これは、「これら5つのメソッドもモックされなかったのはなぜですか？」さらに重要なことは、どの方法をモックするかを決定する際に多くの選択肢がないことです。これは、テストする前にクラスのコード全体を実際に調べたくない場合に適しています。試行錯誤を使用して、それがどのように機能するかを基本的に理解します。

通常、テスト中のクラスから派生するテストクラスの外部サービス呼び出しをオーバーライドできるため、オープン/クローズの原則に従うことは、コードの後に記述されるテストに役立つ可能性があります。TDDでは、これは他の原則ほど必要ではないと思いますが、間違っているかもしれません。

Liskov置換ルールに従うことは、クラスの変更を最小限に抑えて、同じ静的に型付けされたインターフェイスを実装するだけのサポートされていないインスタンスを受け取る場合に最適ですが、適切なテストケースでは発生しない可能性があります一般に、テスト対象のクラスをその依存関係の実世界の実装に渡しません。

最も重要なことは、よりクリーンで、より理解しやすく、保守しやすいコードを書くことを奨励するために、SOLID原則が作成されたことです。TDDもそうでした。したがって、TDDを適切に行い、コードとテストの外観に注意を払えば（そして、フィードバック、API、正確性がすぐに得られるのでそれほど難しくありません）、SOLID原則については一般的に心配する必要はありません。

番号

TDDを使用すると、リファクタリングが継続的に行われるため、グッドプラクティスに従うことが容易になりますが、原則に従うことを強制するものではありません。それがするすべてはあなたが書くコードがテストされることを確認することです。テストを満たすためにコードを記述するときは、好きな原則に従ってください。または原則がまったくありません。

TDDを始めたとき、SOLID Principlesに対する私の理解は一桁大きくなりました。依存関係を模擬する方法について考え始めるとすぐに、コードベースのほぼすべてのコンポーネントに潜在的な代替実装があることに気付きました。そして、単純なパブリックAPIをテストするのがどれほど簡単か。

また、ほとんどの設計パターンをより深く理解することができました。特に戦略パターン。

はい：TDDは、主に優れた設計手法です（そして、二次的なものはテスト手法です）。確かな原則を達成するのに非常に役立ちますが、コードのにおいが多いTDDの（病理学的な）例は依然として可能です。

「テスト駆動開発は設計-TDDの最後の言葉」と名付けられたこの偉大な半端のポッドキャストでは、TDDと堅固な原則との関係が論議されています（上記の結論）。