チームメイトにTDDを使用するよう説得する方法[非公開]

チームでTDDを使用しているのは私だけです。どうすればそれを使用することができますか？

私が引っ張ると、誰かのコードが私のテストを壊してしまい、私がそれらを修正しなければならないのがイライラしています。

github、fork、およびpullリクエストを使用してこの問題を解決し、プルが受け入れられる前にテストに合格する必要がありますか？

私はプロジェクトマネージャーではなく、彼女にそれを使用するよう説得することはできないようです。

私の見方では、テストについて何かを納得させる唯一の方法は、テストが有用であることを実証することです。つまり、テストの失敗はバグを見つけて修正するのに役立ちます。

ただし、問題を説明する方法は、ここではそうではないようです。見て...

...プルすると、誰かのコードがテストを壊してしまい、私はそれらを修正しなければなりません。

私が正しく理解していれば、テストを修正する必要があるということです。まあ、それはテストの失敗がバグを見つけて修正するのに役立つように聞こえませんか？テストがバグの発見に役立たない場合、同僚を説得し始めるのはかなり弱い立場です-彼らは何を得ることができるでしょうか？脆弱なテストコードの退屈な修正

これは行き止まりのように聞こえるかもしれませんが、実際はそうではありません。あなたの最終目標（TDDのための納得）は、それでもかなり理にかなっています。落とさないでください。発見した障害を取り除くことに努力を集中してください。

気になるテストの失敗は、本質的に「誤ったアラート」です。つまり、これらはコードではなくテストのバグです。これらをテストの改善の機会として使用し、優れた信頼性の高いテスト設計の作成方法を学びます。テストに取り組み、「誤った警告」の頻度を減らし、テストされたコードの実際のバグを見つけやすくします。

実際のバグを発見したら、同僚に知らせて修正を手伝ってください。テストでこれらのバグが見つかったことを忘れないでください。それはあなたの同僚を説得するための本当に堅実な基盤を作ります。

チームメンバにTDDの使用を最終的に納得させる場合は、「予備」段階で開発したテスト設計スキルが再び必要になる可能性が高いことに言及する価値があります。考えてみてください...

...テスト駆動開発が経験の浅い同僚に紹介されるとどうなりますか？

最初に期待することは、男たちがくだらないテストを書き始め、学習中に（恐ろしい！）良いテストを壊すことです。彼らがそれを正しく行う方法を見つけるのを助けるために、あなたは良いテストデザインのかなりしっかりした理解を必要とします。

テストで見つけて修正したすべてのエラーは、学習を開始すると、すべてのチームメイトによって何度も繰り返されます。そのような場合（いつ！）、TDDについて肯定的な状態を保ちたい場合は、改善方法をすばやく明確に説明する準備ができているはずです。

テスト駆動開発の使用を奨励したいときに、サイバー道場を運営しました。この種の演習では、コード自体ではなく、コードの記述プロセスに重点が置かれます。

午後をペアで過ごし、同じカタを繰り返しましたが、条件は異なりました。すべてのグループが同時に1つのエクササイズを行うことから始めました。これはベースラインを提供しました。

その後、TDDの基本原則のいくつかについて議論し、全員がパートナーを変えて同じカタを繰り返しました。コードの生成を強調しないために同じ方法を繰り返し、代わりにテストケースの命名プロセスと赤/緑のサイクルに人々を集中させました。

その後、再びカタを繰り返しましたが、約10分ごとに各グループの1人が別のグループに移動し、最近よくある流動的なチーム環境をシミュレートします。

最後の反復では、両方のパートナーを10分ごとに異なるグループに変更しました。これは、TDDを使用すると、あるチームから完全に別のチームへの引き渡しであっても、プロジェクトがすべてのレッド/グリーンサイクルで動作する必要があるため、必ずしも苦痛を感じる必要がないことを実証するのに役立ちました。

興味深いことに、セッション前にTDDを行った人はほとんどいませんでしたが、TDDの知識はカタの最後の繰り返しまで急速に広まり、ほとんどの人はTDDのように考えていたか、少なくともそれを理解することができました有益かもしれません。

一般的に、午後は楽しくて有益であると言われ、現在、職場でCyber​​-Dojoを使用する他の方法を検討しています。

Jon Jaggerによって書かれたCyber​​-Dojoは、この種の演習に非常に適しています。これは、TDDを慎重に実践し、チームダイナミクスについて学習するためのWebベースの統合環境です。人々が問題ではなくTDDのプロセスに集中するのを助けるために選択された多くのカタがあります。また、PythonやRubyからJavaやC ++まで、さまざまな言語をサポートしています。

最も良いのは、カタをした後、戻って参加している各グループの赤/緑の進行（または* 8 'ではないかもしれません）を見ることができることです。それの交通信号は、 TDDのプロセスがどのように機能するかを視覚化するための素晴らしい方法です。

あなたがあなた自身のCyber​​Dojoサーバーをしたい場合は、プロジェクト全体は githubので発見することができ、さらにはそこにあるターンキーのLinuxあなたが既に持っていると仮定する手段、そこからリンクされ、アプライアンスの仮想マシン、VMwareのプレーヤーやVirtualBoxがインストールされ、あなたがアップすることや内で実行されていることができますがアプライアンスをダウンロードする数分！

彼らがTDDに抵抗するなら、それは大丈夫です。多くの人々（私を含む）は、最初に単体テストを書くことに問題を抱えています。

ただし、単体テストがないこと、および単体テストが壊れる問題について質問する必要があります。単体テストは、起こりうる多くのバグを防ぎ、コードのリファクタリングを可能にするセーフティネットです。より高いコード品質とよりクリーンなコードについて説明します。

TDDを使用する利点を説明したビデオを見つけて、会議で公開することが最善だと思います。

彼女が聞くことを拒否した場合、あなたは彼女の上の誰かに行くことを試みることができますが、あなたの上司がとても頑固である場合、それはあまり賢くないかもしれません。

人々に習慣を変えるように説得することは本当に難しいですが、ここにあなたが試すことができるいくつかのものがあります：

• 他の開発者と話をして、TDDが良いアイデアだと思う理由を説明してください。
• 限られた時間でそれを試すように彼ら（または少なくともそれらのいくつか）を説得する
• チームとしてうまく機能するための最小要件を確立してください。必ずしもTDDを実行する必要はありませんが、ユニットテストに失敗しているコードをチェックインするべきではありません。これは、TDDを使用するように説得することとは別の問題であり、対処することがはるかに重要です。
• TDDの試用期間を実施するよう管理職に説得してください。これがなぜ良いプラクティスであり、将来どのように会社の時間とお金を節約するかについて、いくつかの証拠を提供する準備ができている必要があります。

これがまったく機能しない場合は、別の場所での作業を検討することをお勧めします。あなたの人生がかなり楽になる他の会社がたくさんあります。

ここにはわずかに異なる2つの問題があります。TDDを実行させることと、テストに違反することです。

最初の問題については定かではありませんが、個人的には人為的な作業方法であり、すべての種類の開発に適していないと感じています。私はすべての単体テストのスイートを持っているのですが、通常はコードを書いてからテストを書く方が効率的です初期（IMO）。

2番目の問題では、チェックイン時に単体テストが実行されるようにプロジェクトを設定します。これにより、他の開発者はテストを破ったことを知る以外に選択肢がありません。

他の多くの「XにYメソッド/テクノロジーを使用するよう説得する方法」で述べたように、私の答えは常に同じです：例。

それを使用して、より良い（測定可能な）結果を得る。その後、他の人が気づくようにしてください。

既存のプロジェクトでは、そうではありません。インデントスタイルが嫌いなので、従来のコードに中括弧を配置する方法を変更するのと同じです。

たくさんの良いアドバイス。そして今、もう少し...

一度に1人のLudditeの心と心（WHAM）を獲得しなければなりません。喉を強制することを忘れてください。無期限の（それについてはごめんなさい）期間にわたるオブジェクトレッスンがたくさんあります。最終的には、クリティカルマスにぶつかり、「正しい」人を説得します。

WHAMキャンペーンでは、TDDに対する絶え間ない一貫した熱意と熱意が非常に重要です。

テストの中断とコードの変更を教えるべき瞬間に変える必要があります。これはココーダーにとって重要な教訓です。それを個人的にする。IE彼らは、平均以上のきれいなコードを提供することで評判を気にしていますか？彼らは統合テスターが彼らに現実性のチェックを与えたので、彼らが今遅れているコードについて彼らに押しつけられる管理を気にしますか？ジャックは、いくつかの難しいコードを変更したいのですが、副作用を恐れていますか？

コーダーに起因するバグをトラップするために、テスト違反の良い例を収集します。コーダーは、テストの変更を無関係なコードに対する不必要な作業と見なします。彼らはテストが自分のアルセをカバーしただけであることを理解しなければなりません。

グローバルな意味を持つコード（簡単なユーティリティメソッド）を見つけ、テストを作成して、テストがアプリケーション全体で地震の恐れなしに変更できることを実証します。そして、私も感情的な問題を強調するつもりです！

コードをきれいにするまでの簡単な例を集めて（つまり、本番環境に渡されます）、テストコーディングに余分な労力を費やしたにもかかわらず、より速く、より高品質に仕上げられたことを示します。

警告： TDDはOOの設計とコーディングの問題を解決するものではなく、それを克服することはできません（しかし、明らかにそれを明らかにすることはできます）。Ludditesが彼らの無能さのためにテストコードの努力を非難しないでください。

マネージャーを説得するためにもう一度試してみます。あなたが書いたことから、チームメイトに彼女の後ろでTDDをするよう説得することはできないと思います。

彼女の言葉を話さなければなりません。マネージャーはテクノロジーに感銘を受けない傾向がありますが、ビジネス言語を理解しています：

• テストは開発中の時間を節約します。手動テスト（ローカルでバグを再現しようとする、Railsコンソールで遊ぶ...）の代わりに、テストを自動的に実行するためです。

• テストは、何かを変更するたびにバグを簡単に検出できるアプリケーションのメンテナンス中に多くの時間を節約します。テストにはより多くの初期投資が必要であることを説明しますが、長期的には自己負担になります（通常、優れたテストのメンテナンスは迅速かつ簡単です）

• そして、あなたは余分な時間で何をしますか？モアーのものを作成し、それらをモアーマネーにします:)

プログラマーに関しては、この議論を試してみてください（それは私のために働いていました）。 」

期限のある実際のプロジェクトでは、人々は自分が知っていることで仕事を成し遂げることに集中したいと考えています。それはただの人間性です。そして、TDDを一度も学んだことがなければ、あなたはこの状況で彼女と同じになります。私はそれを保証します。

ガベージコレクションの群衆がRAIIを愛し、学び、生きていないのはなぜですか？自動メモリ管理を擁護しながら、ファイル、接続などの一般的なリソースの旧式の管理を保持する方法はありますか？RAIIは、作業が必要な期限がある場合、知らない、理解しない、使用する時間がない技術であるためです。

RAIIを使用しておらず、現在のプロジェクトでRAIIを学習したり理解したりするつもりはありません。TDDを学び、理解しようとしない同僚と同じ。