TDD との敵対的/単純なペアリング:どれくらい効果があるのでしょうか？

Question

私の友人は、職場で TDD によるピンポン ペアリングをどのように行うかを説明していましたが、彼らは「敵対的」アプローチを採用していると言いました。つまり、テスト作成者が実装者にキーボードを渡すと、実装者はテストを合格させるために最も単純な (場合によっては間違ったことも) しようとします。

たとえば、GetName() メソッドをテストしていて、そのテストで「Sally」がチェックされる場合、GetName メソッドの実装は次のようになります。

public string GetName(){
    return "Sally";
}

もちろん、これは (単純に) テストに合格するでしょう。

これにより、コンポーネントの実際の動作や予想される状態をテストするのではなく、特定の既定の値をチェックする単純なテストを排除できると彼は説明します。また、より多くのテストの作成を促進し、最終的には設計を改善し、バグを減らすことにも役立ちます。

それは良いように聞こえましたが、彼との短いセッションでは、1 ラウンドのテストを通過するのに他の方法よりもはるかに長い時間がかかったように見え、追加の価値があまり得られなかったように感じました。

あなたはこのアプローチを使用していますか?もし使用している場合、それが効果を上げているのを見たことがありますか?

Answer 1

それはチームの個性に基づいています。どのチームにも、メンバーの合計である個性があります。優越感を持って受動的攻撃的な実装を実践しないように注意する必要があります。一部の開発者は、次のような実装に不満を感じています。

return "Sally";

このフラストレーションがチームの失敗につながります。私もイライラしていましたが、それが報われるとは思えませんでした。より良いアプローチは、より口頭でコミュニケーションをとり、テストをより適切に実装する方法について提案を行うことだと思います。

Answer 2

非常に効果的です。

そのため、必要な正しい機能を他のプログラマに書いてもらうために、どのようなテストを作成する必要があるかについて、さらに考える必要があります。

キーボードを頻繁に操作しながら、コードを少しずつ構築していきます。

これは非常に面倒で時間がかかることもありますが、このように書かれたコードのバグを修正するために戻ってこなければならないことはほとんどないことがわかりました。

Answer 3

私はこのアプローチを使用しました。すべてのペアで機能するわけではありません。生まれつき抵抗力があり、正直にチャンスを与えようとしない人もいます。ただし、TDD と XP を適切に実行するのに役立ちます。コードベースにゆっくりと機能を追加していきたいと考えています。満足させるために多くのコードが必要となるような巨大なモノリシックなテストを書きたくはありません。簡単なテストがたくさん必要です。また、両方のペアが連携するように、ペア間でキーボードを定期的に行き来させることも必要です。敵対的ペアリングでは、両方を行うことになります。単純なテストは単純な実装につながり、コードはゆっくりと構築され、プロセス全体を通して両方の人が関与します。

Answer 4

時々それが好きですが、常にそのスタイルを使用するわけではありません。時には良い気分転換にもなります。このスタイルを常に使いたいとは思いません。

ただし、初心者にとって、テストが実装をどのように推進できるかを紹介するのに便利なツールであることがわかりました。

Answer 5

(まず、Adversarial TDD は楽しいものでなければなりません。教える機会となるはずです。人間支配の儀式が行われる機会であってはなりません。少しのユーモアを入れる余地がない場合は、チームを去ってください。ごめん。ネガティブな環境で無駄にするには人生は短すぎる。）

ここでの問題は、テストの名前が間違っていることです。テストが次のようになった場合:

foo = new Thing("Sally")
assertEquals("Sally", foo.getName())

そうしたら、きっと「」と名付けられたのでしょう。testGetNameReturnsNameField」。これは悪い名前ですが、すぐにそうであることが明らかになるわけではありません。このテストの正式な名前は「」です。testGetNameReturnsSally」。それがそれです。他の名前はあなたを誤った安心感に陥らせることになります。したがって、このテストの名前は悪くありません。問題はコードではありません。問題はテストですらない。問題はテストの名前です。

代わりに、テスターがテストに「testGetNameReturnsSally」というメッセージが表示された場合、これはおそらく私たちが望んでいることをテストしていないことがすぐに明らかになったでしょう。

したがって、テスターの選択が不適切であることを証明するのは実装者の義務です。テストで要求されるものだけを記述するのも実装者の義務です。

運用環境で非常に多くのバグが発生するのは、コードの動作が期待を下回ったからではなく、それ以上の動作をしたために発生します。はい、予想されるすべてのケースに対する単体テストはありましたが、コードが実行するすべての特別なエッジ ケースに対するテストはありませんでした。プログラマが「これもやったほうがいい、おそらくそれが必要になるだろう」と考えて忘れたためです。それ。TDD がテスト後よりもうまく機能するのはこのためです。そのため、スパイクの後にコードを破棄します。このコードは、あなたが望むことをすべて実行するかもしれませんが、おそらく、あなたが必要だと思っていながら忘れていたことも実行するでしょう。

テスト作成者に本当に必要なものをテストさせる。テストに合格するためのコードのみを記述し、それ以上のコードは記述しません。

RandomStringUtils はあなたの友達です。