単一クラスの単体テスト用の単一または複数のファイル？

組織のガイドラインをまとめるための単体テストのベストプラクティスを調査する際、テストフィクスチャ（テストクラス）を分離するか、1つのクラスのすべてのテストを1つのファイルに保持する方が良いか便利かという問題に直面しました。

ちなみに、純粋な意味での「ユニットテスト」とは、単一のクラス、テストごとに1つのアサーション、モックされたすべての依存関係などを対象とするホワイトボックステストのことです。

シナリオの例は、CheckInとCheckOutという2つのメソッドを持つクラス（Documentと呼ばれる）です。各メソッドは、動作を制御するさまざまなルールなどを実装します。テストごとに1つのアサーションルールに従って、メソッドごとに複数のテストがあります。およびのDocumentTestsような名前を持つ単一のクラスにすべてのテストを配置できます。CheckInShouldThrowExceptionWhenUserIsUnauthorizedCheckOutShouldThrowExceptionWhenUserIsUnauthorized

または、2つの個別のテストクラスを持つことができます：CheckInShouldとCheckOutShould。この場合、テスト名は短縮されますが、特定の動作（メソッド）のすべてのテストが一緒になるように整理されます。

私はどちらのアプローチにも賛否両論があると確信しており、誰かが複数のファイルでルートを行っているのかどうか疑問に思っています。または、単一ファイルのアプローチを選択した場合、なぜそれが良いと感じるのですか？

まれですが、テスト対象の特定のクラスに対して複数のテストクラスを用意することが理にかなっています。通常、異なるセットアップが必要なときにこれを行い、テストのサブセット全体で共有します。

単一のクラスのテストを複数のテストクラスに分割する説得力のある理由を実際に見ることはできません。駆動のアイデアはクラスレベルで結束を維持することであるため、テストレベルでも結束を維持する必要があります。いくつかのランダムな理由：

1. セットアップコードを複製（および複数のバージョンを維持）する必要はありません
2. 1つのテストクラスにグループ化されている場合、IDEからクラスのすべてのテストを簡単に実行できます。
3. テストクラスとクラス間の1対1マッピングにより、トラブルシューティングが容易になります。

クラスの単体テストを複数のファイルに分割せざるを得ない場合は、クラス自体の設計が不十分である可能性があります。Single Responsibility Principleやその他のプログラミングのベストプラクティスに合理的に準拠しているクラスのユニットテストを分割する方が有益なシナリオは考えられません。

さらに、単体テストで長いメソッド名を使用することもできますが、気になる場合は、いつでも単体テストの命名規則を見直して名前を短くすることができます。

テストを複数のクラスに分けることに対する私の議論の1つは、チームの他の開発者（特にテストに精通していない開発者）が既存のテストを見つけるのが難しくなるということです（ジーこのテストは既にあるのでしょうかメソッド？それはどこにあるのだろうか？）また、新しいテストをどこに置くか（このクラスでこのメソッドのテストを書くつもりですが、新しいファイルに置くべきか、既存の一つ？）

テストごとに大幅に異なるセットアップが必要な場合、TDDの実践者によっては、テスト自体ではなく、「フィクスチャ」または「セットアップ」を異なるクラス/ファイルに配置するのを見てきました。

私が採用することを選んだ技術が最初に実証されたリンクを覚えている/見つけることができればいいのですが。基本的には、テスト対象の各メンバーのネストされたテストフィクスチャ（クラス）を含むテスト対象のクラスごとに、単一の抽象クラスを作成します。これにより、当初望まれていた分離が提供されますが、すべてのテストは各場所の同じファイルに保持されます。さらに、これにより、テストランナーで簡単にグループ化およびソートできるクラス名が生成されます。

このアプローチが元のシナリオにどのように適用されるかの例を次に示します。

public abstract class DocumentTests : TestBase
{
    [TestClass()]
    public sealed class CheckInShould : DocumentTests
    {
        [TestMethod()]
        public void ThrowExceptionWhenUserIsNotAuthorized()
        {
        }
    }

    [TestClass()]
    public sealed class CheckOutShould : DocumentTests
    {
        [TestMethod()]
        public void ThrowExceptionWhenUserIsNotAuthorized()
        {
        }
    }
}

これにより、テストリストに次のテストが表示されます。

DocumentTests+CheckInShould.ThrowExceptionWhenUserIsNotAuthorized
DocumentTests+CheckOutShould.ThrowExceptionWhenUserIsNotAuthorized

さらにテストが追加されると、クラス名で簡単にグループ化およびソートされ、テスト中のクラスのすべてのテストが一緒にリストされます。

私が活用することを学んだこのアプローチのもう1つの利点は、この構造のオブジェクト指向の性質です含まれるテストのネストされたクラス。

ちょっと考えてみてください。

クラスごとにテストクラスが1つしかないのはなぜですか？クラステストまたはユニットテストをしていますか？クラスにも依存していますかか？

単体テストは、特定のコンテキストで特定の動作をテストすることになっています。あなたのクラスがすでに持っているという事実CheckInというそもそもそれを必要とする振る舞いがあるべきであることを意味します。

この擬似コードについてどう思いますか：

// check_in_test.file

class CheckInTest extends TestCase {
        /** @test */
        public function unauthorized_users_cannot_check_in() {
                $this->expectException();

                $document = new Document($unauthorizedUser);

                $document->checkIn();
        }
}

これで、checkInメソッドを直接テストしていません。代わりに動作をテストし（幸いにもチェックインすることです;））、リファクタリングする必要がある場合Documentして別のクラスに分割、または別のクラスをマージ、テストファイルは一貫性があり、リファクタリング時にロジックを変更することはなく、構造のみを変更します。

1つのクラスに1つのテストファイルを使用すると、必要なときにいつでもリファクタリングが難しくなり、コード自体のドメイン/ロジックの観点からもテストの意味が少なくなります。

一般に、メソッドではなくクラスの動作をテストすることとしてテストを考えることをお勧めします。つまり、一部のテストでは、予想される動作をテストするためにクラスで両方のメソッドを呼び出す必要があります。

通常、実稼働クラスごとに1つの単体テストクラスから始めますが、最終的には、その単体テストクラスを、テストする動作に基づいて複数のテストクラスに分割する場合があります。つまり、テストクラスをCheckInShouldとCheckOutShouldに分割するのではなく、テスト対象のユニットの動作によって分割することをお勧めします。

1.何がうまくいかないかを検討する

最初の開発中、あなたは何をしているのかをかなりよく知っているので、両方のソリューションはおそらくうまくいくでしょう。

変更がずっと後にテストが失敗すると、さらに興味深いものになります。次の2つの可能性があります。

1. あなたは真剣に壊れていますCheckIn（またはCheckOut）。この場合も、単一ファイルと2ファイルの両方のソリューションで問題ありません。
2. CheckInand CheckOut（およびおそらくテスト）の両方を修正しましたが、それらの両方に対しては意味がありますが、両方を一緒にしたわけではありません。ペアの一貫性を壊しました。その場合、テストを2つのファイルに分割すると、問題を理解しにくくなります。

2.使用されるテストの検討

テストには2つの主な目的があります。

1. プログラムを自動的にチェックすることはまだ正しく機能します。テストが1つのファイルにあるか、複数のファイルにあるかは、この目的には関係ありません。
2. 人間の読者がプログラムを理解するのを助けてください。密接に関連する機能のテストをまとめておけば、これははるかに簡単になります。それらの一貫性を見ることは理解への迅速な道だからです。

そう？

これらの両方の観点から、テストをまとめておくと役立つことがありますが、害はありません。