私の友人は、職場で TDD とピンポン ペアリングを行う方法を説明していました。つまり、テスト作成者がキーボードを実装者に渡すと、実装者はテストに合格するために最も単純な (そして時には間違ったことを) しようとします。
たとえば、GetName() メソッドをテストしていて、テストが「Sally」をチェックする場合、GetName メソッドの実装は次のようになります。
public string GetName(){
return "Sally";
}
もちろん、これは（単純に）テストに合格します。
彼は、これにより、コンポーネントの実際の動作や期待される状態をテストするのではなく、特定の定型値をチェックする単純なテストをなくすことができると説明しています。また、より多くのテストを作成し、最終的には設計を改善してバグを減らすのにも役立ちます。
いい感じですが、彼との短いセッションでは、1回のテストを通過するのに他の場合よりもはるかに時間がかかったように見え、多くの余分な価値が得られたとは感じませんでした.
あなたはこのアプローチを使用していますか?
それは非常に効果的です。
他のプログラマーに必要な正しい機能を書かせるために、どのテストを作成する必要があるかについてもっと考える必要があります。
キーボードを頻繁に渡すことでコードを構築します
非常に面倒で時間がかかる可能性がありますが、このように記述されたコードのバグを修正するために戻ってくることはめったにありません。
私はこのアプローチを使用しました。すべてのペアで機能するわけではありません。一部の人々は自然に抵抗力があり、正直なチャンスを与えません. ただし、TDD と XP を適切に実行するのに役立ちます。ゆっくりとコードベースに機能を追加したいと考えています。満足するのに多くのコードを必要とする巨大なモノリシックなテストを書きたくないでしょう。たくさんの簡単なテストが必要です。また、ペア間でキーボードを定期的にやり取りして、両方のペアが接続されていることを確認する必要があります。敵対的ペアリングでは、両方を行っています。簡単なテストは簡単な実装につながり、コードはゆっくりと構築され、両方の人がプロセス全体に関与します。
私は時々それが好きです-しかし、そのスタイルをずっと使用しないでください. 時には気分転換にもなります。いつもこのスタイルを使いたいとは思いません。
ただし、テストが実装をどのように推進できるかを紹介する初心者向けの便利なツールであることがわかりました。
(まず、Adversarial TDD は楽しいものであるべきです。教える機会であるべきです。人間の支配の儀式の機会であってはなりません。少しのユーモアの余地がない場合は、チームを離れてください。申し訳ありません。ネガティブな環境では、人生は無駄に短くなります。)
ここでの問題は、名前の悪いテストです。テストが次のようになった場合:
foo = new Thing("Sally")
assertEquals("Sally", foo.getName())
それなら「testGetNameReturnsNameField」という名前だったに違いない。これは悪い名前ですが、すぐにそうであるとは限りません。このテストの適切な名前は " testGetNameReturnsSally" です。それがそれがすることです。他の名前は、あなたを誤った安心感に陥れています。したがって、テストの名前は不適切です。問題はコードではありません。問題はテストでさえありません。問題はテストの名前です。
代わりに、テスト担当者がテストに " testGetNameReturnsSally" という名前を付けた場合、これがおそらく必要なテストではないことがすぐに明らかになります。
したがって、テスト担当者の不適切な選択を実証することは、実装者の義務です。テストが要求するものだけを書くのも実装者の義務です。
本番環境で非常に多くのバグが発生するのは、コードが予想を下回ったからではなく、それ以上のことをしたからです。はい、予想されるすべてのケースの単体テストがありましたが、コードが実行したすべての特別なエッジケースのテストはありませんでした。それ。これが、TDD が test-after よりもうまく機能する理由です。スパイク後にコードを破棄するのはそのためです。コードはあなたが望むすべてのことを実行するかもしれませんが、おそらくあなたが必要だと思って忘れていたことを実行するでしょう。
テスト ライターに、本当に必要なものをテストするように強制します。テストに合格するためのコードのみを記述し、それ以上は記述しません。
RandomStringUtils はあなたの友達です。
それはチームの個性に基づいています。すべてのチームには、そのメンバーの合計である個性があります。優越感に満ちたパッシブアグレッシブな実装を実践しないように注意する必要があります。一部の開発者は、次のような実装に不満を感じています
return "Sally";
この欲求不満は、チームの失敗につながります。私は欲求不満の中にいましたが、それが報われるのを見ませんでした. より良いアプローチは、テストをより適切に実装する方法について提案する、より口頭でのコミュニケーションだと思います。