いくつかの古いレガシーコードをリファクタリングしている間、私は可能な限り単一責任の原則を適用しようとしたので、1つの目的だけを持つ多くのクラスに行き着きました。それは問題ありませんが、これらの新しいクラスの単体テストを作成しようとすると問題が発生します。一部のクラスは、テストの設定が難しいため、テストが非常に困難です。単一のテストケースを作成するには、4〜5個のモック/スタブを作成する必要があります。すべてのコードをカバーしたい場合は、複数のテストケースを作成する必要があるため、お尻が痛くなります。
テストをセットアップするのが難しい（他の多くのクラスに依存しているため）コードの臭いはありますか？これをどのように解決しますか？
ボブおじさんがSRPについて言っていることは次のとおりです。
クラスには、変更する理由が1つだけある必要があります。
「クラスは1つのことと1つのことだけを行う」とは言っていないことに注意してください。言い換えれば、1つを除くすべての責任が不変である場合、またはすべてが一緒に変更される場合、クラスが複数の責任を持つことは完全に有効です。
彼のアジャイルパターン、原則、および実践の本の中で、ボブおじさんは次のように述べています。
SRPのコンテキストでは、変更の理由となる責任を定義します（117）。
と：
一方、アプリケーションが[複数の]責任を異なる時間に変更するような方法で変更されていない場合は、それらを分離する必要はありません。確かに、それらを分離することは不必要な複雑さのにおいがするでしょう。（118）
とはいえ、共同作業者が多すぎるクラスは匂いであり、慎重に検討する必要があります。