クラスの単体テストを分離することは悪い習慣ですか？[閉まっている]

私のクラスは通常、最大で約5〜20のメソッドを持っています。これは、単体テストを持つクラスがメソッドの約2倍（counting dataProviders、setUpなど）を持っていることを意味します

私は、テストを2〜3つのクラスに分けようと考えました。単一の責任の原則に従っても、20のメソッドではなく、それぞれ10のメソッドを持つ2つのテストクラスを好むからです。

それは悪い習慣ですか？テストクラスは垂直に成長しますが、クラスのすべてのテストを1つだけにするとよいですか？

特定の質問に答えるには、テストを複数のクラスにグループ化することが良い決定である可能性が絶対にあります。

単体テストコードは他のコードと同様です。適切な設計原則（DRY、GRASP、KISS、SOLID、YAGNIなど）に従う必要があります。多くの場合、テストコードを構成するロジックはドメインロジックよりも単純であるため、特定のポイントの多くはそれほど重要ではありませんが、テストをすべて同じように記述するときは、それらを念頭に置いてください。

質問について考えるときに簡単に適用できるいくつかの原則が思い浮かびます：

読みやすさ

理想的には、テストが作成されたら、それをもう一度見る必要はありません。しかし、どのコードでも同じことが言えます。実際には、要件が変わるため、コードを書くよりもコードを読み取る方がはるかにわかります。最善を尽くしたとしても、作成したテストでは、それが何をしたのかを十分に検証できなかった場合があります。その時点で、戻って何が問題だったかを突き止める必要があります。40から50のテストメソッドのクラスでそのテストメソッドを見つけるのは難しく、それらを簡単に区別できるようにメソッドに名前を付けることの複雑さは言うまでもありません。

高い凝集力

各テストクラス（他のクラスと同様）には明確な焦点を当てる必要があります。テスト対象のクラスの特定のメソッドに対して多数の異なるテストケースがある場合、特定のテストが単一のものを検証するときのように、それらのテストメソッドを別のクラスに置き、フォーカスを反映するように名前を付けます。

単体テストを最初に配置する場合と比較して、どのように編成するかはほとんど重要ではありません。

ビジネスコードのモジュールまたはクラスは、1つの単位として理解し、さらに開発する必要があるものです。これが、一貫性があり、全体として把握しやすくするなどの主な理由です。テストスイートは、すべて合格する必要があるケースのコレクションにすぎません。互いに特定の関係はありません。理想的には、二度とそれを扱う必要がないでしょう。通常は、他のテストと特定の関係を持たないテストをさらに追加し、単体テストフレームワークを除いてクライアントコードから呼び出されることはありません。

したがって、単体テストを含むクラスをどのように編成するかという問題は、アプリケーション自体を構成するクラスをどのように編成するかほど重要ではありません。いずれにしても、それらを適切に構築されたマクロ構造として扱うことは想定されていません。

テストを1つのファイルに入れます。通常、すべてのクラスファイルに対して、テストファイルがあります。通常、ファイル名に「テスト」を追加します。

たとえば、「Foo」というクラスがある場合、対応する「FooTests」ファイルがあります。このように、すべてのコードファイルについて、コードファイルとテストファイルの間に1対1の関係があります。

これにより、一貫性が提供され、開発者がテストを見つけて最新の状態に保つことが容易になります。通常、テストはコード分析/メトリックスから除外されるため、ファイルが大きい場合でも、コード全体のヘルスメトリックスを損なうことはないので、ユニットテストコードが多数含まれているテストファイルがあることは悪いことだとは思いません。

ソフトウェア開発における悪い習慣の定義が、変更への対処とカプセル化に役立たないものであると言えば、クラスとテストを1対1の関係に維持しないことは悪い習慣だと私は言うでしょう。下記のようなことで発生するコード臭です。

明らかに、何かと同じように例外がありますが、テストを作成するときはそのことを覚えておいてください。

私のクラスには、通常、最大5〜20のメソッドがあります。

クラスのいずれかに20（またはそれ以下）のメソッドがある場合、その種のクラスはそもそもクラスが多すぎることを示しています。これは、ユニットテストで、クラスをもう少し分解して、テストを始める前に責任を分散させる必要があるかもしれないことを示唆する場所です。

同じクラスにそれらを保持するかどうかについては、理解しやすいので、可能であれば1つのクラスに保持することをお勧めします。1対1の接続は、多くの時間が経過した後に簡単に把握できます。ちょうど経験から。

メソッドが5つ以下の場合でもユニットテストが巨大であることがわかると、セットアップコードが多すぎるか、オブジェクトが異常に大きいことがわかります。

オブジェクトを構築するためのビルダーパターンをまだ試していない場合は、テストする前にオブジェクトを構築する方法を大幅に削減できます。したがって、単体テストクラスを短くして、より多くのクラスに分類する必要性を減らします。