TDDでは、最初にTestまたはInterfaceを記述する必要がありますか？

私はテストが開発を促進する必要があることを知っている限り、c＃を使用してTDDを学んでいます。つまり、最初にテストに合格するために最低限のコードを書いてからリファクタリングを行ってから失敗するテストを書きます。

しかし、「実装ではなく、インターフェイスするプログラム」とも言われているため、最初にインターフェイスを記述します。ここから混乱が始まります。最初にInterfaceを書いている場合、2つのことに違反しています。

1. インターフェイス用に記述されたコードはtestによって駆動されません。

2. 単純なクラスでそれを書くことができるのは、明らかに最低限のものではありません。

インターフェースのテストを書くことから始めなければなりませんか？実装なしで何をテストするのですか？

この質問がそれについて愚かに残念に思えるが、私は全く混乱しています。文字通りに物事を取っているかもしれません。

最初の違反（「インターフェイス用に記述されたコードはテストによって駆動されない」）は無効です。ささいな例を使用しましょう。計算機クラスを作成していて、加算演算を作成しているとします。どのようなテストを作成できますか？

public class CalculatorTest {
    @Test
    public void testAddTwoIntegers() {
        Calculator calc = new Calculator();
        int result = calc.add(2, 2)
        Assert.assertEquals(4, result);
    }
}

テストでインターフェイスが定義されました。そのadd方法ですよね？add2つの引数を取り、それらの合計を返します。後で複数の計算機が必要であると判断し、その時点で（この場合）Javaインターフェースを抽出します。そのクラスのパブリックインターフェイスをテストしたため、テストは変更されません。

より理論的なレベルでは、テストはシステムの実行可能な仕様です。システムへのインターフェースは、そのシステムのユーザーが操作する必要があり、テストは相互作用を定義する最初の方法です。

インターフェイスデザインとテストデザインを分離できるとは思わない。それらのための相互作用を定義し、設計のテストは、同じ精神的な操作です- とき私はインターフェイスにこの情報を送信、私は期待して、特定の結果を。入力に問題がある場合、このエラーが発生することが予想されます。この設計作業を紙の上で行い、それからテストを書くこともできますし、同時にそれらを行うこともできます-それは本当に問題ではありません。

を書くとき、私たちは何をしていinterfaceますか？私たちはコードを書いていますか、それとも設計していますか？

私はテスト駆動設計の概念のファンではありませんが、テスト駆動開発が大好きです。個人的には、テストを作成する前にインターフェイスを設計してクラスを事前に設計すると、最良の結果が得られました。インターフェイスをコードとしてカウントしません。インターフェイスは、TDDを使用して実装するデザインです。作業中に進化を変える可能性がありますが、それは（テストリストとともに）私のロードマップです。

私は暴言を始める前に停止しますが、うまくいけばそれがあなたがそれについて考えるのに役立つ方法です。

TDDでは、最初にTestまたはInterfaceを記述する必要がありますか？

それはあなたがどのように正統派/宗教的にTDDをしたいかに依存します。

私はTDDを学んでいます

学習しているので、あなたに合った個人的なワークフローを得るために実験する必要があります。

1. 本に従ってそれをしたい場合は、最初にテストを書きます。コードがまったくない状態で開始するため、明らかに失敗します。次に、テストに合格するためのコードを作成します。それが行われた場合、リファクタリングのためのある種のセーフティネットを提供するテストがあるため、既存のコードを自由にリファクタリングできます。インターフェイスの使用を決定することは、何らかのリファクタリングです。

2. TDDかどうか：質問、インターフェイスを使用するかどうかは、そもそも興味深いものではありません。もちろん、確かな場合は、複数のオブジェクトに分散する異なる動作があるため、インターフェイスの使用を検討するのは理にかなっています：たとえば、異なる宛先に何らかの出力がある場合、それを介して実装するのが理にかなっていますインターフェースWriterで、出力用の異なるクラス（FileWriter、Printerなど）を持っています。インターフェースに書き込むことは一般的な言い方ですが、それは、すべてにインターフェースを使用するという意味ではありません。時々、それは多くへの間接的なレベルです。ところで サービスについても同じことが言えます。しかし、それは別のトピックです。

3. 一方、別の方法でテスト駆動を開発することもできます。テスト容易性のためにコードを設計します。つまり、テストを簡単に作成できますが、後でテストを作成します。とにかくテストする限り、前もってテストを書いても問題はありません。

TDDまたはBDDとは、最初にドメインインターフェースを実行し、次に私の解釈でそれらに対してテストを作成することを意味します。インターフェイスの実装には予期される動作があります。

インターフェイスにはテスト可能なロジックが含まれていないため、コードの前にテストが行​​われます。これは、テストの対象となる構造です。

私は次のようにします

1. セミフォーマルな振る舞いを書く（与えられた：いつ：その後:)

2. インターフェースを記述する（メソッドをカプセル化する動作をホストするため）

3. それが識別するテストを書く（与えられたものを入力し、いつ呼び出すか、それからテストする）

4. テストに合格するために、コンクリート（インターフェイスを実装するクラス）の書き込み/変更

インターフェイスを設計する前にテストを作成しないでください。どのような種類のテストを作成するか（テスト設計）を考えている場合、アプリケーションを同時に設計（設計）することもできません。同時に2つのことを考えないでください。懸念の分離について聞いたことがありますか？コードの物理構造だけでなく、思考プロセスにも適用されます。

最初にアプリケーションを設計する方法を決定します。これは、インターフェイスとこれらのインターフェイス間の関係を設計することを意味します。これを行うまで、テストについて考え始めるべきではありません。インターフェイスが何であるかがわかったら、最初にインターフェイスを作成してからテストを作成するか、最初にテストを作成してから作成します。後者の場合、明らかにテストをコンパイルすることはできません。テストの前にインターフェイスを作成しても、TDD哲学に害はなく、違反もありません。

プロジェクトへの組み込みがアトミックである限り、インターフェイス/コード/テストを同時に記述してもかまいません。

上司がTDDに信心している場合を除き、空のインターフェイスを記述する必要があります->テスト->最小限のコード（無意味なステップ）->テストを追加->無意味なコードを追加->テストを追加->最終的に実際のコードを作成- >完了。