tdd - ソフトウェアショップをTDDに変換する方法は？

Question

私が働いている店の中でTDD開発を推進したいと思っています。向こうの多くの先輩はユニットテストで働いていなかったか、データベースにぶつかっていたユニットテストをしました。

私はいくつかの良い議論、トレーニングのための本、移行を容易にするための可能なコーチを持ってきたいです。

score 14 · Accepted Answer

TDDを開発者から押し上げるのは非常に難しいことがよくあります。私がしがちなのは、TDDの利点について可能な限り話し、可能な限り、TDDの要素を少しずつ紹介することです。

彼らが気にしない場合は、単体テストを含む新しいプロジェクトを開始し（マネージャーがテストカバレッジを気にすることはめったにありません）、その方法で自分で開発を開始します。チームの他のメンバーにゆっくりとメリットを示し、いくつかの改宗者を獲得してみてください。他に数人の開発者がいる場合は、トレーニングのために管理をプッシュし始めます。

他の開発者のために、ランチアンドラーンを実行することを提案することもできます。教えることは学ぶための最良の方法であり、あなたはうまくいけば仲間を得るでしょう。運が良ければ、上司にランチアンドラーン用のピザを買うように話しかけることができ、誰もが恩恵を受けることができます。

score 3 · Accepted Answer

ロブ P が言ったように、私はまた、説教をすると声がかすれてしまい、誰も聞いていないことに気づきました。それを行い、その部分を目に見えるようにしておくことで、結果をより速く、より広く得ることができました。質問に対してオープンであり、それを強制しないでください。励まし、称賛しますが、説教はしません。

それをテスト結果の公開と組み合わせて、それを自動化して、おそらく電子メールを送信できます。あなたの方法がどれほど優れているかを人々に示すために、多くの微妙なリマインダーが必要です。

score 3 · Accepted Answer

TDD プリンシパルを既存の製品に忍び込ませる良い方法は、バグの単体テストを書き始めることだと思います。このようにして、ビルドプロセスの一部として実行できる場合は特に、プロジェクトの不可欠な部分となる回帰テスト用の単体テストのセットをゆっくりと構築し始めます。

唯一のハードルは、既存のコードがテストに抵抗する可能性があることですが、それはリファクタリングを行う別の言い訳にすぎません。

人々がメリットに気づき始めると勢いが増しますが、その道を開拓する必要があります。

score 3 · Accepted Answer

何がうまくいくかはわかりませんが、確実にうまくいかず、避けるべきいくつかのことをお伝えできます。

私がコードを書き、あなたがテストを書く

これはいつも最初に出てきます。人々は、あなたはテストに熱心なので、テストを書くのはあなたであるべきだと思い込んでいます。これはまったく機能せず、要点全体を見逃しています。

壊れているテストを書いたので、修正する必要があります。

コードのテストを書き始めると、必然的に他の誰かがそれらのテストを壊します。その後、修正を依頼すると、多くの場合、それはあなたの責任であると言われます。これは必ずしも彼らが意地悪であるとは限りません。単にプロセスを理解していないだけかもしれません。これは、管理バックアップが必要な場所です。

私は始めたばかりで、誰もが従います。

他の人が言ったように、管理サポートのない TDD は非常に困難です。「クールエイドを飲まない」開発者がいる場合、彼らは常にテストを破り、気にかけません。彼らを信じさせることができないなら、それが彼らの仕事だと経営陣に伝える必要があります。

最終的に私を動かしたのは、バグが多すぎてプロジェクトが崩壊するのを見たときでした。根本的に間違ったことをしていると確信しました。少し調べた結果、自動テストにたどり着き、少し決意して基本を独学しました。おそらく、仲間の開発者と同様のプロジェクト (私たちは皆、少なくとも 1 つのプロジェクトを持っています...) について話し合うことで、彼らが何か新しいことに挑戦したいと思うかもしれないことに気付くのに役立つでしょう。

score 2 · Accepted Answer

例によって導く：

記述したすべてのコードで TDD を使用する
機会があればすぐにメリットを示します (単体テストによって検出されたリグレッション、または単体テスト環境で再現されたインシデント)。
「機能するクリーンなコード」を提供する
あなたの支援を他の人に提案する
独断的にならないでください - TDD は特効薬ではありません
単体テストを可視化します。テストするコードと一緒にコンパイルする必要があります

score 1 · Accepted Answer

プロジェクトに十分な単体テストがない場合は、単体テストがあれば回避できたであろう問題データベースのバグを指摘できます。

TDD やその他のコード宗教を推し進めることに関しては、気にしないでください。

一部の人々 (および一部の種類のコード) にとって、TDD は素晴らしいものです。一部の人々はそのように動作せず、テストファーストの恩恵を受けません。彼らがテストを完全に避けない限り、それは問題ではないと思います。

score 0 · Accepted Answer

「ボトムアップ」で導入される TDD の大きな課題は、プッシュが押し寄せてくると (締め切りが近づくと必然的にそうなるのと同様に)、経営陣がテストに重点を置いていることを上書きすることです。テストします! プロジェクトを終了する必要があります!」

もちろん、これは TDD の利点が実際に発揮されるまさにその状況 (締め切りが迫っている、大量のバックログ、約束どおりに進んでいない、優先順位とタスクの急速な変化につながる) です。経営陣は振り返って、「TDD を試してみましたが、まったく役に立ちませんでした」と言います。

tdd - ソフトウェアショップをTDDに変換する方法は？

7 に答える 7

Related