TDDの「明白な実装」は最初にコードを意味し、その後にテストを意味しますか？

私と私の友人は比較的新しいTDDで、「Obvious Implementation」テクニック（Kent Beckによる「TDD By Example」より）について論争しています。私の友人は、実装が明らかな場合、その新しい動作をテストする前に、先に進んでそれを書くべきだと言っています。そして実際、この本はこう言っています：

簡単な操作をどのように実装しますか？それらを実装するだけです。

また：

操作を実装する方法を知っていることが確実な場合もあります。どうぞ。

著者が意味するのは、最初にテストしてから「実装する」ことです。「フェイクイット（ 'Till You Make It）」や実装段階でより小さなステップを必要とする他のテクニックとは対照的です。また、これらの引用の後、著者は「Obvious Implementation」を行うときに「赤いバー」（テストに失敗）を取得することについて話します。テストなしで赤いバーを取得するにはどうすればよいですか。

しかし、「自明」とはまだ最初のテストを意味するという本の引用を見つけることができませんでした。

どう思いますか？実装が「自明」な場合（TDDによると）、最初にテストするか、その後にテストする必要がありますか？それを言っている本やブログの投稿を知っていますか？

私はあなたの解釈に同意します-それはまだRed Green Refactorであり、リファクタービットは省かれています;）

そのため、最初に失敗したテストを記述してから、「可能な限り単純な」設計をゆっくりと構築する代わりに、明白なソリューションを実装します。

それを言っている本やブログの投稿を知っていますか？

ベックの本はまさにそれを言っていると私は主張します。

彼は言い​​続ける

ただし、明白な実装のみを使用することにより、自分の完全性を要求しています。心理的には、これは壊滅的な動きになる可能性があります。 あなたが書いたものが、実際にテストに合格する可能性のある最も単純な変更ではない場合はどうなりますか？ パートナーがあなたにもっと簡単なものを見せたらどうしますか？あなたは失敗です！あなたの世界はあなたの周りで崩れます！あなたは死にます。フリーズします。

コードが存在する前にコードが存在しない場合、コードを記述することにより、どのようにしてテストに合格することができますか？

明らかに、ここには厳格で速いルールはありません。結局アジャイルでしたので、繰り返しながら適応することができますし、適応すべきです:)

部分的には単純な操作に依存します。TDDの練習を重ねるにつれて、頻繁にテストが不十分だったり、実際にはまったくテストしなかったものが見つかることがありますが、それはすべて学習曲線の一部です。

また、TDDでは、ライブコードにコミットする前に、インターフェイスと実装をテストできることを忘れないでください。

あなたは何かを実装する方法を知っているかもしれませんが、どのくらいの頻度で最初に完璧なクラス/メソッドなどを書くのですか？途中でいくつかの微調整をせずに、または何かを変更するときに6か月後にコードを1回または2回ステップスルーしますテストのサンドボックスに再び自信を。

もちろん、テストは最初にコードを正しく書くことを意味するものではありませんが、変更はテストによって駆動され、テストがコードの最初のクライアントになり、テストは非常に低コストであり、より重要なのは変更のリスクがないことです開発中に自信と自由が得られます。

本当に良いカバレッジとより高い品質を得ようとするなら、TDDを練習するにつれて、必要なカバレッジのレベルの感覚を身につけていきます。

些細なコードの場合、ユニットテストはまったくないはずだということを学びました。

例：メソッドをローカル変数にマップするjava getter / setterメソッドがある場合、このためのユニットテストは過剰になります。

これが著者の意味するところかもしれません

> "How do you implement simple operations? Just implement them."
> "Sometimes you are sure you know how to implement an operation. Go ahead."