TDD：最初の単体テストの前に何が起こりますか？

私はTDDの理論をほとんど理解していますが、どのように始めればよいのかわかりません。個人プロジェクトのユニットテストを書いて実現するために座っています。。。何をテストしているのかわかりません。どのオブジェクト、どの機能など

例えば、私たちの家族が雑用の割り当てを管理するのに役立つアプリを書きたいとしましょう。ここに私の頭の中にいくつかの質問があります：このアイデアから最初のテストに行くにはどうすればいいですか？始める前にどれくらい決める必要がありますか。また、テストの作成を開始した後、どれだけ把握する必要がありますか データをテキストファイルとデータベースのどちらに保存するかなどの決定はいつ行いますか？開始する前にユーザー受け入れテストを行う必要がありますか？UIを設計する必要がありますか？スペックが必要ですか？（これらの例の質問の少なくともいくつかがおそらく「灰色の領域」にあることを理解しています）。

最初の単体テストにたどり着くというタイトルの質問に加えて、サンプルプロジェクトのようなプロジェクトの最初の単体テストがどのように見えるかも例を示してください。

フィーチャーのリストから始めて、フィーチャーごとにユーザーストーリーを書き、次にストーリーごとにテストの説明を書きたいと思います。

設計について少し考えてから、テストの説明を選んでコーディングを開始します：red-green-refactor。

すべてのテストに合格するまで繰り返します。

はい、受け入れテストは、適切なストーリーに添付されたこの一環として検討する必要があります。

あなたは、TDDが最初からデザインをどのように扱っているかを発見しました。最初のテストを作成する前に、最初の機能がどのようなものになるか、そしてその機能が機能している場合はプログラムがどのように見えるかを考える必要があります。

TDDを使用しない開発者もそれについて考える必要があります-しかし、彼らは何かに「飛び込む」だけで何かを書き始めることができます。しかし、「何か、何でも」は、あなたが書くことを始めたと思っていたプログラムを提供することへの道に常にあるとは限りません。とは？さて、プログラムが機能している場合、プログラムはどのようになりますか？どのテストに合格しますか？

私たちの家族が雑用の割り当てを管理するのに役立つアプリを書きたいです。

涼しい。そのアプリが機能していた場合、それは何をしますか？まあ、日課はおそらく人に割り当てることができますよね？

Person fred = new Person("fred")
Chore mow = new Chore("mow the lawn");
mow.assignTo(fred);
assertEquals(fred, mow.whoIsAssigned());

始まりがあります。開始する必要がある場所ではなく、必ずしも開始するのに最適な場所ではありませんが、それは場所です。コードにサポートしてほしいものです（ただし、より良い名前を思い付くことができると確信していますが）。そこから始めて、失敗するのを見てください。通過させます。それをきれいにします。泡立て、すすぎ、繰り返します。

ええ、TDDにはこの問題があります。だからこそ、今は行動駆動開発をお勧めします。

手動で開始します。ユーザーストーリーに似たものを書き留めます。

• ユーザーとして
• 私はときにショッピングカートを追加]を選択し、私は、製品がバックグラウンドで透過的に追加することにしたいです
• 買い物を中断せずに続けられるように

では、その目標をサポートする機能は何ですか（「So that」の部分）。

• アイテムがショッピングカートに追加されたとき
  • ユーザーのショッピングカートには新しいアイテムが含まれます
  • カート内のアイテムの合計が1つ増えます
  • ユーザーをリダイレクトしないでください
  • 今すぐチェックアウトオプションが利用可能になります
• ショッピングカートに2つの商品があり、ユーザーがチェックアウトすることを選択した場合
  • ユーザーはチェックアウトページにリダイレクトされます
  • 両方のアイテムが表示されます

これらはすべて可能なことであり、手動で確認する必要があります。

しばらくこれを行います。次に、優れた開発者のように、冗長部分を自動化する方法を探し始めます。これは、プラットフォームが何であるかによって異なりますが、ほとんどの場合、利用可能な適切なフレームワークがあります。

.NetにはWebページを自動化するWatiNがあります。または、APIをテストする場合は、xUnitまたはMSpecにSubspecを追加することをお勧めします（テストフレームワークでもこれを行うことができます。このスタイルの考え方をサポートしています）。

Rubyには自動化テスト用のキュウリと低レベルAPIテスト用のrspecがあります

JavascriptにはジャスミンとqUnitがあります。

点点々

このアイデアから最初のテストに進むにはどうすればよいですか？始める前にどれくらい決める必要がありますか。また、テストの作成を開始した後、どれだけ把握する必要がありますか

アプリケーションを一口サイズのストーリーに分けます。（「ユーザーとして、アイコンをダブルクリックしてプログラムを起動します。」または「ユーザーとして、ブラウザーを開いてプログラムにアクセスします。」

次に、ストーリーをいくつかのタスクに分けます。（たとえば、Eclipseでプロジェクトを作成し、コードリポジトリを設定します）コーディングタスクに到達したら、最初のテストを作成します。

データをテキストファイルとデータベースのどちらに保存するかなどの決定はいつ行いますか？

確信が持てない場合は、どれがよりシンプルに見えるかを選択してください。（おそらくテキストファイル）間違いを犯したことに気付いたら、リファクタリングしてください。テストが適切に構成されていれば、バックエンドを変更して、意図しない副作用が発生するのをキャッチできるはずです。

最初のテストを書く直前に行う実際のこと、つまりテストリストを作成することについての言及が答えに含まれていないことに驚いています。テストリストは、他の回答で言及されているストーリー作成および設計フェーズによって通知され、探していると思われるテストを作成するための直接の前兆です。

TDDの詳細については、Kent Beckによる例によるテスト駆動開発をお勧めします。彼はまた、プロセスのすべてのステップでのケントによる説明とともに、純粋なTDDスタイルの自明でないライブラリの開発に続くTDDスクリーンキャストを持っています。たとえそれが（必然的に）不自然な環境で行われたとしても、それは実際のTDDの素晴らしい例だと思います。

最初の単体テストの前に、何をしたいのかを考え、それをどのようにテストするかを考えます。次に、そのテストを作成し、失敗することを確認し、合格するコードを実装します。

すすぎ、繰り返しなど

私にとって、それはあなたがそれを少しテストする方法についての考え方であり、それが重要であり、それがあなたのデザインを動かすことができるものです。