TDDでの赤ちゃんの歩数はどのくらいですか？

今日、私たちはTDDをトレーニングしていて、次の誤解のポイントを見つけました。

タスクは、入力 "1,2"が3である数値の合計を返すためのものです。（C＃で）私が書いたのは：

numbers = input.Split(',');
return int.Parse(numbers[0]) + int.Parse(numbers[1]); //task said we have two numbers and input is correct

しかし、他の人はそれを別の方法で行うことを好みました。まず、入力 "1,2"について、次のコードを追加しました。

if (input == "1,2")
   return 3;

次に、入力 "4,5"のテストをもう1つ導入し、実装を変更しました。

if (input == "1,2")
   return 3;
else if (input == "4,5")
   return 9;

そしてその後、彼らは「さて、今はパターンが見える」と言って、私が最初にやったことを実装しました。

2番目のアプローチはTDDの定義により適していると思いますが、...厳密にすべきでしょうか？私にとっては、些細な赤ちゃんのステップをスキップして、何もスキップしないことを十分に確信している場合は、それらを「ツインステップ」に結合してもかまいません。私が間違っている？

更新。私はそれが最初のテストではないことを明確にしないことで間違いを犯しました。すでにいくつかのテストが行​​われているため、「return 3」は実際に要件を満たすための最も単純なコードではありませんでした。

テストに合格する最も簡単なコードを記述します。

私が見る限り、あなたのどちらもそうしなかった。

ベビーステップ1。

テスト：入力 "1,2"に対して、3である数値の合計を返します

テストを失敗させます。

throw NotImplementedException();

テストに合格する：

return 3;

ベビーステップ2。

テスト：入力 "1,2"に対して、3である数値の合計を返します

テスト：入力 "4,5"の場合、9である数値の合計を返します

2番目のテストは失敗するので、合格させます。

numbers = input.Split(',');
return int.Parse(numbers[0]) + int.Parse(numbers[1]);

（if ... returnのリストよりも簡単）

この場合、明らかな実装については間違いなく議論できますが、厳密に赤ちゃんのステップでそれを行うことについて話している場合、これらは正しいステップ、IMOです。

論点は、2番目のテストを書かないと、後から明るい火花が出て、コードを「リファクタリング」して読むことができるということです。

return input.Length; # Still satisfies the first test

そして、両方の手順を踏まずに、2番目のテストを赤くしたことはありません（テスト自体が疑わしいことを意味します）。

2番目の方法は、麻痺するほど愚かなことだと思います。私は十分に小さなステップを作成することの価値を理解していますが、それらの小さな接合子（赤ちゃんと呼ぶことさえできない）のステップを作成することは、単純で時間の無駄です。特に、あなたが解決しようとしている元の問題がそれ自身ですでに非常に小さい場合。

私はそれが訓練であり、原則を示すことについてより多くを知っています、しかし、私はそのような例が良いよりも悪いTDDを行うと思います。赤ちゃんの歩みの価値を示したいなら、少なくとも価値のある問題を使いましょう。

ケントベックは、彼の著書「Test Driven Development：By By Example」でこれを取り上げています。

あなたの例は「明白な実装」を示しています-あなたは合計2つの入力値を返したいです、そしてこれは達成するためのかなり基本的なアルゴリズムです。あなたの反例は、「あなたがそれを作るまで偽造する」ことになります（非常に単純なケースですが）。

明らかな実装はこれよりもはるかに複雑になる可能性があります-しかし、基本的にはメソッドの仕様が非常に厳しい場合に開始されます-たとえば、クラスプロパティのURLエンコードバージョンを返す-たくさんの時間を無駄にする必要はありません偽のエンコーディング。

一方、データベース接続ルーチンでは、もう少し考えてテストする必要があるため、明らかな実装はありません（すでに他のプロジェクトで何度か書いたとしても）。

本から：

私が実際にTDDを使用するとき、私は通常、これら2つの実装モードを切り替えます。すべてがスムーズに進み、入力するものがわかったら、私は明白な実装の後に明白な実装を入れます（私に明らかなことを確認するために毎回テストを実行します）コンピュータにはまだ明らかです）。予想外の赤いバーが表示されるとすぐに、バックアップを取り、実装を偽装し、適切なコードにリファクタリングします。自信が戻ったら、Obvious Implementationsに戻ります。

私はこれを法律の手紙に従っていると考えていますが、その精神ではありません。

赤ちゃんの手順は次のとおりです。

可能な限りシンプルですが、シンプルではありません。

また、メソッドの動詞は sum

if (input == "1,2")
   return 3;

合計ではなく、特定の入力のテストです。

私にとっては、いくつかの些細な実装手順をわずかに些細なものにまとめるのは問題ないようです-私もいつもそうしています。私は、TDDを毎回手紙に追うことについて信心深くする必要はないと思います。

OTOHこれは、上記の例のような本当に些細な手順にのみ適用されます。一度に完全に心に留めることができない、および/または結果について110％の確信がない場合、より複雑なものについては、一度に1ステップずつ進むことを好みます。

この質問が示すように、TDDの道を最初に設定するとき、ステップのサイズは混乱を招く問題になる可能性があります。テスト駆動型アプリケーションの作成を初めて開始したときによく尋ねた質問は次のとおりです。私が書いているテストは、アプリケーション開発の促進に役立ちますか？これは些細なことのように思えるかもしれませんが、一部とは関係ありませんが、しばらくは私と一緒にハングアップします。

これで、アプリケーションの作成に着手するとき、通常はテストから始めます。テストのステップのどれだけが、私がやろうとしていることの理解に大きく関係しています。クラスの振る舞いが頭の中でほとんどわかっていると思うなら、そのステップは大きなものになります。私が解決しようとしている問題があまり明確でない場合、ステップは単にXという名前のメソッドに行くことを知っていて、それがYを返すことです。この時点で、メソッドはパラメータさえも持たず、メソッドの名前と戻り値の型が変更される可能性があります。どちらの場合も、テストが私の開発を後押ししています。彼らは私のアプリケーションに関することを教えてくれます：

私の頭の中にあるこのクラスは実際に働くのでしょうか？

または

一体どうやってこんなことをするつもりなの？

ポイントは、瞬きで大きなステップと小さなステップを切り替えることができるということです。たとえば、大きなステップが機能せず、明確な方法がわからない場合は、小さなステップに切り替えます。それでもうまくいかない場合は、さらに小さなステップに切り替えます。それから、私が本当に行き詰まった場合、三角測量のような他のテクニックがあります。

私のようにあなたが開発者でありテスターではない場合、TDDを使用するポイントはテストを書くことではなく、コードを書くことです。小規模なテストにメリットが与えられない場合でも、大量の小さなテストの作成にこだわらないでください。

TDDを使ったトレーニングを楽しんでいただけたでしょうか。私見では、より多くの人々がテスト感染した場合、世界はより良い場所になります:)

単体テストに関する入門書では、同じアプローチ（本当に、本当に小さいように見えるステップ）を読み、「どれだけ小さいのか」という質問に対する答えとして、次のような（言い換え）が好きでした。

ステップが機能することの自信についてです。必要に応じて、本当に大きな一歩を踏み出すことができます。しかし、しばらく試してみれば、当然のことと思っている場所に多くの見当違いの自信を見つけるでしょう。したがって、テストは、事実に基づいた信頼を構築するのに役立ちます。

だから、多分あなたの同僚は少し恥ずかしがり屋です:)

テストが成功する限り、メソッドの実装が無意味であるという点ではありませんか？2番目の例では、テストの拡張はより速く失敗しますが、どちらの場合でも失敗するようにできます。

私は、どちらも最も単純な実装ではないと言っている人々に同意しています。

方法論が非常に厳密な理由は、可能な限り多くの関連するテストを書くことを義務付けているからです。1つのテストケースの定数値を返し、それをパスと呼ぶのは問題ありません。強制的に戻って、あなたが本当にあなたのプログラムからナンセンス以外のものを得るために欲しいものを指定することができます。このような些細なケースを使用すると、いくつかの点で自分自身を撃ちますが、原則は、「多すぎる」ことをしようとするときに仕様のギャップにミスが忍び込み、要件を可能な限りシンプルな実装にレンダリングすることですテストは、実際に必要な動作の固有の側面ごとに作成する必要があります。