TDDを使用する正しい方法がどれなのか混乱しています

TDDの背後にあるアイデアと、チームがTDDを使用する方法を把握しようとしています。NUnit + Moqを使用した次のテストケースがあります（メモリで書き込むだけで、サンプルがコンパイルされるとは限りませんが、説明が必要です）。

[Test]
public void WhenUserLogsCorrectlyIsRedirectedToLoginCorrectView() {
    Mock<IUserDatabaseRepository> repoMock = new Mock<IUserDatabaseRepository>();
    repoMock.Setup(m => m.GetUser(It.IsAny())).Returns(new User { Name = "Peter" });        

    Mock<ILoginHelper> loginHelperMock = new Mock<ILoginHelper>();
    loginHelperMock.Setup(m => m.Login(It.IsAny(), It.IsAny())).Returns(true);
    Mock<IViewModelFactory> factoryMock = new Mock<IViewModelFactory>();
    factoryMock.Setup(m => m.CreateViewModel()).Returns(new LoginViewModel());

    AccountController controller = new AccountController(repoMock.Object, loginHelperMock.Object, factoryMock.Object)

    var result = controller.Index(username : "Peter", password: "whatever");

    Assert.AreEqual(result.Model.Username, "Peter");
}

AccountControllerには3つの依存関係があります。これを模擬しています。コントローラー内で調整すると、ログインが正しいかどうかを確認できます。

私の心をつまずくのは... TDDで理論的に最初にテストスイートを記述し、そこからコードをビルドする必要がある場合、操作を実行するために使用する必要があることを事前に知っておくにはどうすればよいですか。これらの3つの依存関係と、操作によって特定の操作が呼び出されることはありますか？それは、依存関係をモックしてクラスを分離するために実装する前に、テスト中のサブジェクトの内部を知る必要があるようなもので、ある種の書き込みテスト-コードの作成-必要に応じてテストを変更します。

当然、コードの内部についての知識がなく、テストを表現するだけで、ILoginHelperが必要であるように表現でき、「魔法のように」コードを書く前に、成功したログインでユーザーを返すと（そして最終的には）基礎となるフレームワークがそのように機能しないことを認識してください（たとえば、完全なオブジェクトの代わりにIDだけを返す）。

TDDを間違った方法で理解していますか？複雑なケースでの典型的なTDDプラクティスはどれですか？

ありがとうございました

TDDで理論的には、最初にテストスーツを作成し、それからコードをビルドする必要がある場合

ここにあなたの誤解があります。TDDは最初に完全なテストスイートを作成することではありません。それは誤った神話です。TDDは小さなサイクルで作業することを意味し、

• 一度に1つのテストを書く
• テストを「グリーン」にするために必要なだけのコードを実装する
• リファクタリング（コードとテスト）

したがって、テストスイートの作成は1つのステップで行われるのではなく、「コードが記述される前」に行われるのではなく、問題のコードの実装と織り交ぜられます。

例に適用：依存関係のないコントローラ（プロトタイプのようなもの）の簡単なテストから始める必要があります。次に、コントローラーを実装し、リファクタリングします。その後、コントローラーがもう少し行うことを期待する新しいテストを追加するか、既存のテストをリファクタリング/拡張します。次に、新しいテストが「緑」になるまでコントローラーを変更します。このようにして、テストとテスト対象の単純な組み合わせから始め、複雑なテストとテスト対象に終わります。

このルートをたどると、ある時点で、コントローラーがその作業を行うための入力として必要な追加データがわかります。これは確かに、次のテストを設計するときではなく、コントローラーメソッドを実装しようとしたときに発生する可能性があります。これは、短時間でメソッドを実装するのをやめ、不足している依存関係の導入を最初に開始するポイントです（おそらく、コントローラーのコンストラクターのリファクタリングによる）。これにより、既存のテストのリファクタリングが簡単になります。TDDでは、通常、最初にコンストラクターを呼び出すテストを変更し、その後に新しいコンストラクター属性を追加します。そして、テストのコーディングと記述が完全に絡み合うところです。

私の心をつまずくのは... TDDで理論的に最初にテストスーツを記述し、そこからコードをビルドする必要がある場合、どのように私は私の操作を実行するために使用する必要があることを事前に知っているはずですか？これらの3つの依存関係と、操作によって特定の操作が呼び出されることはありますか？それは、依存関係をモックしてクラスを分離するために実装する前に、テスト中のサブジェクトの内部を知る必要があるようなもので、ある種の書き込みテスト-コードの作成-必要に応じてテストを変更します。

気分が悪いですよね？そして、それは-コントローラのテストが何らかの方法で不正確だったり「不良」だったりするのではなく、「制御」されるべきものがなくなる前にコントローラをテストしたいのです。:)

私の要点は、「ビジネスルール」と「実際のアプリケーションロジック」のレベルでTDDを使い始めると、TDDがより自然に感じるようになるということです。コントローラーは通常、他のコンポーネントへの委任のみを扱うため、委任が正しく行われたかどうかをテストするには、委任先のオブジェクトを知る必要があります。唯一の問題は、実際のロジックを実装する前に実行しようとした場合です。たとえば、TDDをより「動作指向」の方法で行うことで、LoginHelperの実装を試みることをお勧めします。それはより自然に感じるでしょう、そしてあなたはおそらくその利点のより多くを見るでしょう。

つまり、より一般的な答えとしては、TDDは必要なコードを記述する前にテストを作成する手法ですが、どの種類のテストを指定するのかということではありません。コントローラーは通常、コンポーネントのインテグレーターであるため、多くのモックを必要とする単体テストを作成します。アプリケーションロジック（注文、ユーザー認証の検証などのビジネスルールなど）を記述する場合、通常は状態ベースのテスト（与えられた入力と目的の出力）となる動作テストを記述します。この違いは、多くの場合、TDDコミュニティではモック主義と統計主義と呼ばれています。私は両方の方法が正しいことを主張する（小さな）グループの一部です。それは、それらが異なるトレードオフを提供するだけであり、したがって、上記のような異なるシナリオに役立ちます。

TDDはテストファーストの方法ですが、本番用コードを書く前にテストコードを書くのに多くの時間を費やす必要はありません。

この例では、ケントベックのTDDに関する独創的な書籍（1）で説明されているTDDの考え方は、

AccountController controller = new AccountController()

var result = controller.Index(username : "Peter", password: "whatever");

Assert.AreEqual(result.Model.Username, "Peter");

最初、あなたはあなたが仕事をするためにあなたが必要とするであろうすべてを知りません。ユーザー名を持つモデルを提供するIndexメソッドを備えたコントローラーが必要になることを知っているだけです。あなたはそれがどうやってそれをするのかまだ知りません。自分の目標を設定しました。

次に、利用可能な任意の手段を使用して、最初は正しい結果をハードコーディングするだけでそれを機能させることができます。次に、後続のリファクタリング（およびさらにテストを追加）で、一度に1ステップずつ高度な機能を追加します。TDDを使用すると、前進する必要があるのと同じくらい小さいステップを踏むことができますが、スキルと知識が許す限り、自由にステップを踏むこともできます。テストコードと本番コードの間の短いサイクルを取ることで、実行するすべての小さなステップに関するフィードバックを得て、今行ったことがうまくいったかどうか、それが以前に働いていた他のものを壊したかどうかをほぼ即座に知ることができます。

（2）のロバートマーティンは、テストコードの作成と製品コードの作成の間の非常に短いサイクルタイムを提唱しています。

概念的に単純な単体テストでは、結局この複雑さすべてが必要になるかもしれませんが、そもそもこのようなテストを書くことはほぼ確実にありません。

最初に、最初の6行の複雑な設定は、自己完結型の再利用可能なフィクスチャコードに分解する必要があります。保守可能なプログラミングの原則は、ビジネスコードと同じようにテストコードに適用されます。2つ以上のテストに同じフィクスチャを使用する場合は、テスト内で1行しか邪魔にならないように別のメソッドにリファクタリングするか、クラスセットアップコードにリファクタリングして何もないようにする必要があります。

しかし、より重要なことは、最初にテストを作成しても、テストが永久に変更されないことを保証するものではありません。メソッド呼び出しの共同編集者がわからない場合、ほとんどの場合、最初の試行で正しいと推測することはできません。パブリックAPIが変更された場合、ビジネスコードと共にテストコードをリファクタリングしても問題はありません。そもそもTDD の目的は、正確で使いやすいAPIを作成することですが、これが100％になることはほとんどありません。常に要件事実の後で変化します。そしてこれは、ストーリーの最初のイテレーションを書いたときに存在しなかった協力者を絶対に必要とします。その場合は何もすることはありませんが、弾丸をかじって、アプリケーションに合わせて既存のテストを変更します。これらは、引用したセットアップコードの大部分がテストスイートに組み込まれる機会です。

それは、依存関係をモックしてクラスを分離するために実装する前に、テスト中のサブジェクトの内部を知る必要があるようなもので、ある種の書き込みテスト-コードの作成-必要に応じてテストを変更します。

はい、ある程度は行います。TDDの仕組みを誤解しているとは思いません。

問題は、他の人が述べたように、最初は非常に奇妙に感じられ、この方法で行うのはほとんど間違っているということです。私の意見では、実際にTDDの最大の利点であると私が感じていることを示しています。コードを記述する前に、要件を適切に理解する必要があります。

プログラマーとして、私たちはコードを書くのが好きです。それで、要件をすくい取り、できるだけ早く立ち往生するために、私たちにとって「正しい」「自然な」と感じるものは何ですか。コードベースを構築してテストすると、設計上の問題が徐々に明らかになります。したがって、リファクタリングして修正すると、物事は徐々に改善され、目標に向かって進みます。

これは楽しいですが、特に効率的な方法ではありません。ソフトウェアモジュールが最初に何をすべきかを適切に把握し、テストを停止してからコードを記述する方がはるかに優れています。リファクタリングが少なく、テストメンテナンスが少なくて済むので、ブロック外の優れたアーキテクチャを実現できます。

私はTDDをあまり行いませんが、「100％コードカバレッジ」のマントラは無意味だと思います。特にあなたのような場合に。しかし、TDDを採用することには、コード全体で設計と保守が適切に行われていることを確認する上で非常に役立つため、依然として大きな価値があります。

要約すると、この奇妙なものを見つけているという事実は、おそらくあなたが正しい道を進んでいることの良い兆候です。

データのモックは、ダミーデータを使用する練習にすぎません。

ARRANGE | ACT | 主張する

TDDは通常、テストを作成し、それらのテストを「合格」することを検証することです。最初は、そのテストを検証するコードがまだ作成されていないため、最初のテストは失敗します。これは実際には特定の種類のテストだと思います。「赤/緑」のテスト。これは、今日の「テスト駆動」メソッドのソースです。

一般に、テストは、より大きな画像コードを機能させるロジックの小さなナゲットを検証します。関数の最小レベルから始めて、より複雑な関数まで進んでいきます。

はい、セットアップまたは「モッキング」が多少強烈になる場合があります。そのため、moqフレームワークを使用することをお勧めします。ただし、コアビジネスロジックに焦点を当てている場合、テストは、それが機能するという有益な保証になります。期待どおり、意図したとおり。

個人的には、コントローラーが使用しているすべてのものが動作するようにテストされているため、私はコントローラーをテストしていません。通常、フレームワークをテストする必要はありません。