ジュニアプログラマーにテストを作成させる方法は？[閉まっている]

十分なテストを書いていないジュニアプログラマーがいます。
私は彼に2時間ごとに「テストを書いてくれましたか？」
私たちは試しました：

• デザインがシンプルになることを示す
• それを示すことは欠陥を防ぐ
• 悪いプログラマだけがしないと言って、それをエゴなものにする
• 彼のコードにはNULL参照があり、テストしなかったため、今週末、2人のチームメンバーが作業する必要がありました。

私の仕事には最高品質の安定したコードが必要であり、通常、誰もがそれを「理解」し、テストを実行する必要はありません。私たちは彼にテストを書かせることができることを知っていますが、あなたがそれに入ったときに書かれたものが有用なテストであることは誰もが知っています。

もっと動機を知っていますか？

これは、最も難しいことの 1つです。あなたの人々にそれを取得させる。

時々、ジュニアレベルのプログラマーが「理解する」のを助け、高齢者から適切なテクニックを学ぶのに最適な方法の1つは、ペアプログラミングを少し行うことです。

これを試してください。次のプロジェクトで、ジュニアガイと自分または別のシニアプログラマーをペアにします。彼らは協力して、「運転」（キーボードでタイプしている人）と「コーチング」（ドライバーの肩越しに見て、提案、間違いなどを指摘しながら）を交互に行います。リソースの無駄のように見えるかもしれませんが、次のことがわかります。

1. これらの人たちが一緒になって、十分に高速で高品質のコードを生成できること
2. 後輩が正しい道に沿って指示する上級者と「理解する」のに十分な知識を持っている場合（例：「さて、先に進む前に、この機能のテストで書いてみましょう。」）リソースの価値は十分にあります。それにコミットします。

たぶん、グループの誰かに ユニットテスト101をしてプレゼンテーションをKate Rhodesにし。うまく配信されれば、人々をテストに興奮させる素晴らしい方法だと思います。

あなたができるもう1つのことは、ジュニア開発者にボウリングゲームカタの練習をさせて、テスト駆動開発の学習を支援することです。これはJavaですが、どの言語にも簡単に適応できます。

すべてのコミットの前にコードレビューを行い（1分間の "この変数名を変更しました"の場合でも）、コードレビューの一環として、ユニットテストをレビューします。

テストが実施されるまで、コミットを承認しないでください。

（また-彼の作品がテストされなかった場合-なぜ最初にプロダクションビルドに含まれていたのですか？テストされていない場合は、入れないでください。週末に仕事をする必要はありません）

私自身、私が見つけて修正したすべてのバグはテストとして表現するように主張し始めました：

1. 「うーん、そうではない...」
2. 考えられる問題を見つける
3. テストを作成し、コードが失敗することを示す
4. 問題を解決する
5. 新しいコードが合格することを示す
6. 元の問題が解決しない場合はループする

私はものを叩きながらもこれをやろうとします、そして私はほぼ同じ時間に完了します、部分的なテストスイートがすでに配置されているだけで。

（私は商用のプログラミング環境に住んでいるわけではなく、特定のプロジェクトで作業している唯一のコーダーです。）

私が偽のプログラマーだと想像してみてください...マルコ。私がそれほど昔に学校を卒業したことがなく、実際にテストを書く必要がなかったと想像してください。私がこれを強制しない、または要求しない会社で働いていると想像してください。OK？良い！今、会社がテストの使用に切り替えており、彼らが私をこれに合わせようとしていると想像してください。これまで研究をしなかったかのように、これまでに述べた項目に対していくぶん不快な反応をします。

これを作成者から始めましょう：

デザインがシンプルになることを示す。

どうすればもっと書くことができ、物事がより簡単になります。私は今より多くのケースを取得するなどのタブを維持する必要があります。これは私に尋ねるともっと複雑になります。詳細を教えてください。

それを示すことは欠陥を防ぎます。

そんなこと知ってる。これがテストと呼ばれる理由です。私のコードは良好であり、問​​題がないかチェックしたので、これらのテストがどこで役立つかわかりません。

悪いプログラマだけがそうしないと言って、それをエゴなことにする。

ああ、だから私はあまり使い慣れたテストをしていないからといって、私は悪いプログラマだと思います。私はあなたを侮辱し、積極的にイライラします。私は格言よりも支援とサポートが欲しいです。

@ Justin Standard：新しいpropectの開始時に、ジュニアガイと自分または別のシニアプログラマーをペアにします。

ああ、これは非常に重要なので、物事がどのように行われるかを確認するためにリソースが費やされ、物事がどのように行われるかを支援してくれる人がいます。これは役に立ち、私はもっとそれを始めるかもしれません。

@ Justin Standard：Kate RhodesによるUnit Testing 101プレゼンテーションを読んでください。

ああ、それは興味深いプレゼンテーションで、テストについて考えさせられました。それは私が考慮しなければならない点でいくつかの点を打ち出しました、そしてそれは私の意見を少し揺らしたかもしれません。

もっと説得力のある記事や、これが物事を行うための正しい方法だと思うようになるのに役立つ他のツールが欲しいです。

@ Dominic Cooney：時間をかけて、テスト手法を共有します。

ああ、これはテクニックに関して私に何が期待されているかを理解するのに役立ちます、そしてそれは私のバッグにもっとアイテムを入れて、私は再び使うかもしれません。

@ Dominic Cooney：質問、例、および本に答えます。

質問に答える要人（人）がいると助かります。良い例は素晴らしいです、そしてそれは私に狙いを定めるために、そして参照を探すために何かを与えます。これに直接関係のある本は非常に参考になります。

@ アダムヘイル：サプライズレビュー。

なんと言っても、あなたは私がまったく備えていない何かを生み出した。私はこれに不快に感じますが、最善を尽くします。私はこれが恐ろしくなり、再びこれがやってくるのを穏やかに理解するでしょう、ありがとう。しかし、恐怖の戦術はうまくいったかもしれませんが、コストがかかります。ただし、他に何も機能しない場合、これは必要なプッシュにすぎない可能性があります。

@ Rytmis：テストケースがある場合のみ、アイテムは完了したと見なされます。

おお、面白い。私は本当にこれをしなければならないことを知っています、そうでなければ私は何も完了していません。意味あり。

@ jmorris：取り除く/犠牲を払う。

まぶしさ、まぶしさ、まぶしさ -私が学ぶ可能性があり、サポートと支援があれば、私はチームの非常に重要で機能的な部分になることができます。これは現在私のハンディキャップの1つですが、長くはかからないでしょう。しかし、それがわからなければ、私は行くことを理解しています。わかると思います。

結局、私のチームのサポートは、これらすべてにおいて大きな役割を果たす。人に時間をかけて手伝ってもらい、良い習慣を身につけてもらうことはいつでも歓迎です。その後、良いサポートネットがあれば素晴らしいでしょう。誰かが後で何度か来て、コードを調べて、レビュー自体ではなく、友好的な訪問としてすべてがどのように流れているかを確認することは常にありがたいです。

推論、準備、指導、フォローアップ、サポート。

多くのプログラマーが合理的なレベルでのテストの価値を認めていることに気づきました。「ええ、私はこれをテストするべきだと知っていますが、私は本当にこれを迅速に実行する必要がある」というようなことを聞​​いたなら、あなたは私の意味を知っています。ただし、感情的なレベルでは、実際のコードを書いているときにのみ何かが成し遂げられると感じています。

したがって、目標は、テストが実際に何かが「完了」したときに測定する唯一の方法であることを彼らに理解させ、テストを作成する本質的な動機を与えることです。

でも、それは思ったよりずっと難しいです。「私は本当に急いでいるので、後でこれをリライト/リファクタリングしてからテストを追加します」という言い回しに沿って多くの言い訳が聞こえます。もちろん、フォローアップは決して起こりません。 「再来週ただ忙しいと。

これが私がすることです：

• 初めて...「このプロジェクトは共同で行います。テストを記述し、コードを記述します。テストの記述方法に注意してください。それが、私たちのやり方です。このあたりで、それが私があなたに期待することです。」

• その後、「これで完了です。すばらしいです。最初に、開発を推進しているテストを見てみましょう。テストはありません。それが完了したら、私に知らせてください。コードの確認を再スケジュールします。テストを作成するために助けが必要な場合は、お知らせください。お手伝いします。」

彼はすでにこれをやっています。本当に。彼はそれを書き留めていないだけです。納得できませんか？彼が標準の開発サイクルを経験するのを見てください：

• コードを書く
• コンパイルする
• 実行してそれが何をするかを確認する
• 次のコードを書く

ステップ3はテストです。彼はすでにテストを行っており、手動で行うだけです。彼にこの質問をしてください：「今日のコードがまだ機能していることを明日どうやって知るのですか？」「ほんの少しのコードです！」と彼は答えます。

質問：「来週はどうですか？」

彼が答えをもらえないときは、次のように質問します。

それが自動ユニットテストのすべてです。

ジュニアプログラマーとして、私はまだテストを書く習慣を身につけようとしています。明らかに、新しい習慣を身につけるのは簡単ではありませんが、これが私にとって何がうまくいくかを考えると、コードレビューとコーチング/ペアプログラミングに関するコメントを+1する必要があります。

また、テストの長期的な目的を強調する価値もあります。昨日機能したものが、今日、翌週、翌月にも機能することを確認します。私が言ったのは、答えをざっと流し読みするときに、そのことが言及されていなかったからです。

コードレビューを行う場合（そうすることを決定した場合）、若い開発者が彼を倒すことではなく、コードを改善することを知っていることを確認してください。そうすれば、彼の自信が損なわれる可能性が低くなるからです。そしてそれは重要です。一方、あなたがどれだけ知っているかを知ることはそうです。

もちろん、私は本当に何も知りません。しかし、私はその言葉が役に立つことを望みます。

編集：[ ジャスティンスタンダード ]

自分を落とさないでください。あなたが言わなければならないことはほとんど正しいです。

コードレビューに関するあなたのポイント：あなたが見つけることは、ジュニア開発者がプロ​​セスで学ぶだけでなく、レビュー担当者も学ぶということです。コードレビューの誰もが、それを協調プロセスにするかどうかを学びます。

あなたが置くために持っている場合は率直に言って、それは彼が何かを得ることに多くの努力を、あなたは彼がちょうどチームのために良いフィットではないかもしれない、と行く必要がある場合が思想と折り合いをつける必要があるかもしれません。今、これは必ずしも彼を解雇することを意味しません...それは彼のスキルがより適している会社のどこかで見つけることを意味するかもしれません。しかし、他に場所がないなら...あなたは何をすべきか知っています。

私は彼もかなりの新入社員（<1年）で、おそらく最近学校を卒業していると思います...その場合、彼は企業環境での仕事のやり方に慣れていない可能性があります。私たちのほとんどが大学で逃げることができるようなもの。

これが事実である場合、私が作品を見つけた1つのことは、一種の「驚きの新規採用レビュー」を行うことです。これまでに行ったことがないかどうかは関係ありません...彼はそれを知りません。ただ彼に座って、あなたに彼のパフォーマンスを調べて実際の数字を見せようとしていることを伝えてください...通常のレビューシートを取り（正式なレビュープロセスはありますか？）、必要に応じて見出しを変更します公式と彼が立っている場所を彼に示します。テストを行わないだけでパフォーマンスレーティングに悪影響を与えるという非常に形式的な設定で彼を見せれば、彼はポイントを獲得できると期待しています。あなたは彼の行動が実際にそれが賢明な報酬であるかどうかに関係なく彼に影響を与えることを彼に示さなければなりません。

公式ではないので、これを避けた方がいいかもしれません...しかし、あなたはそれを行うのは当然のことだと思います。おそらく、彼を解雇して新しい人を雇うよりもずっと安くなるでしょう。

私自身もジュニアプログラマーでしたが、私はあなたのジュニアデベロッパーと同じような状況にいると感じたときの様子を明らかにしたいと思いました。

私が最初に大学を出たとき、私は現実世界に対処するために私をかなり備えさせていなかったことがわかりました。はい私はいくつかのJAVAの基本といくつかの哲学（質問しないでください）を知っていましたが、それはそれについてでした。私が最初に仕事を得たとき、控えめに言ってもそれは少し困難でした。私がおそらく最大のカウボーイの1人だったとしましょう。コメントのない小さなバグ修正/アルゴリズム/テスト/ドキュメントを一緒にハックして、ドアから出荷します。

私は幸運にも、親切で非常に忍耐強い上級プログラマーの監督下にいることができました。幸運なことに、彼は私と一緒に座って、非常にハッキングされたtogethorコードを1〜2週間費やすことにしました。彼は私がどこで間違っていたのか、cとポインターの細かい点を説明してくれました（男の子が私を混乱させました！）。約1週間でかなりまともなクラス/モジュールを作成することができました。私が言えることは、もし上級開発者が正しい道に沿って私を助けるために時間を費やしていなかったら、おそらくあまり長くは続かなかっただろうということです。

幸いなことに、2年後、同僚の何人かが私を平均的なプログラマーと見なしてくれることを願っています。

家に帰る

1. ほとんどの大学は、現実の世界に向けて学生を準備するのが非常に悪い
2. ペアプログラミングは本当に役に立ちました。それはすべての人に役立つと言っているわけではありませんが、私にとってはうまくいきました。

懸念がある場合は、「最高品質の安定したコード」を必要としないプロジェクトにそれらを割り当て、jrに任せます。開発者は失敗します。彼らに彼らのバグを修正するために「週末にやって来る」ものにさせてください。たくさん昼食をとり、ソフトウェア開発の実践について話してください（講義ではなくディスカッション）。やがて、割り当てられたタスクを実行するためのベストプラクティスを習得して開発します。

誰が知っているか、彼らはあなたのチームが現在使用しているテクニックよりも優れたものを思いつくかもしれません。

ジュニアプログラマーまたは誰かがテストでその値を認識しない場合、彼らにそれを実行させることは困難です...期間。

バグを修正するために、ジュニアプログラマーに週末を犠牲にさせたでしょう。彼の行動（またはその欠如）は直接彼に影響を与えていません。また、テストのスキルを向上させないと、昇進が見られない、および/または昇給が見られないことを明確にします。

結局、あなたの助け、励まし、メンタリングがあっても、彼はあなたのチームに適していないかもしれないので、彼に行かせて、それを手に入れる人を探しましょう。

私はすべてのコミットをレビューするコードについてのRodeoClownのコメントを2番目に述べます。彼がそれをかなりの回数行うと、彼はものをテストする習慣に入るでしょう。

そのようなコミットをブロックする必要があるかどうかはわかりません。私の職場では、誰もがすべてに無料でコミットでき、すべてのSVNコミットメッセージ（差分付き）がチームにメールで送信されます。

注：これを行う予定がある場合は、本当にthunderbirdのカラー差分アドオンが必要です。

私の上司または私（2つの「シニア」コーダー）はコミットを読み終えてしまい、「ユニットテストを追加するのを忘れた」などのメッセージがある場合は、メールをフリックするか、その人にチャットして、その理由を説明しますユニットテストか何かが必要でした。他の誰もが何が起こっているかを見るのに最適な方法であるため、コミットも読むことをお勧めしますが、ジュニア開発者はあまりコメントしません。

「こんにちは、ボブ、今朝私がやったコミットを見たことはありますか。なんとかして、コミットを読んでコミットを確認できるこの巧妙なトリックを見つけました。使い方！"

注：「シニア」開発者が2人、ジュニア開発者が3人います。これはスケーリングされない場合や、より多くの開発者とプロセスを少し調整する必要がある場合があります。

1. コードカバレッジをレビューの一部にします。
2. バグを修正するための前提条件として、「バグを明らかにするテストを作成する」を作成します。
3. コードをチェックインする前に、一定レベルのカバレッジが必要です。
4. テスト駆動開発に関する優れた本を見つけ、それを使用して、テストファーストが開発を加速する方法を示してください。

たくさんの心理学と役立つ「メンタリング」テクニックですが、正直なところ、これは「明日も仕事をしたいのならテストを書く」ことになります。

あなたは、あなたが適切であると思うどんな条件でもそれをソファーすることができます。しかし、実際のところ、プログラマーは、コードをまとめてチェックインするだけで報酬を得ているわけではありません。コードを注意深く組み立て、テストを組み立て、コードをテストしてから、すべてをチェックインすることで報酬を得ています（少なくともそれはあなたの説明から、それがどのように聞こえるかです。）

したがって、誰かが仕事を拒否する場合は、明日家にいることができることを説明してください。そうすれば、その仕事をしてくれる人を雇うことになります。

繰り返しになりますが、それが必要だと思う場合は、これらすべてを穏やかに行うことができますが、多くの人はLife In The Real Worldの大きなハードスラップを必要とするだけであり、それを彼らに与えることで彼らに好意を示します。

幸運を。

しばらくの間、彼の仕事の説明を変更して、テストの作成とテストの保守のみを行うようにします。経験の浅い新しい人のために、多くの企業がこれを始めたとき、しばらくそうしていると聞きました。

さらに、彼がその役割にある間にチャレンジを発行します。a）現在のコードで失敗するa）ソフトウェアの要件を満たすテストを記述します。うまくいけば、彼はいくつかの堅実で徹底的なテストを作成し（プロジェクトを改善し）、コア開発に再統合するときのテストを書くのが上手くなるでしょう。

edit>ソフトウェアの要件を十分に満たすことは、コードがそのテストケースを考慮に入れることをまったく意図していない、または必要としない場合に、意図的にコードを壊すためのテストを書くだけではないことを意味します。

同僚がテストを書く経験がない場合、おそらく彼または彼女は単純な状況を超えてテストするのに苦労しており、それが不十分なテストとして現れています。これが私が試してみるものです：

• 時間をかけて、依存関係注入、エッジケースの検索などのテスト手法を同僚と共有します。
• テストに関する質問への回答を申し出ます。
• しばらくの間、テストのコードレビューを行います。良いテストの例であるあなたの変更をレビューするよう同僚に依頼してください。彼らのコメントを見て、彼らがあなたのテストコードを本当に読んで理解しているかどうかを確認してください。
• チームのテスト哲学に特に適合する本がある場合は、その本を彼または彼女に渡してください。コードレビューのフィードバックやディスカッションがその本を参照しているので、彼または彼女が取り上げてフォローするスレッドを持っている場合に役立ちます。

私は特に恥/罪悪感の要素を強調しません。テストは広く採用されている優れたプラクティスであり、優れたテストの作成と維持は専門家の好意によるものであるため、チームメイトが週末を仕事に費やす必要がないことを指摘する価値はありますが、私はそれらの点に注意を払いません。

あなたが本当に「タフになる」必要がある場合は、公平な制度を導入してください。彼らが独り占めされているように感じるのを好む人はいません。たとえば、チームは特定のレベルのテストカバレッジを維持するためにコードを必要とする場合があります（ゲームは可能ですが、少なくとも自動化は可能です）。テストを行うには新しいコードが必要です。コードレビューを行う際に、レビュー担当者にテストの品質を考慮するよう要求する。等々。このシステムの導入は、チームのコンセンサスに基づくものでなければなりません。ディスカッションを慎重にモデレートすると、同僚のテストが期待と異なる他の根本的な理由が明らかになる可能性があります。

彼に教えることは彼のメンターの責任です。どのように彼/彼女にテストする方法を教えていますか。あなたは彼とプログラミングを組んでいますか？ジュニアはおそらく、xyzの適切なテストを設定する方法を知りません。

学校の新入生として、彼は多くの概念を知っています。いくつかのテクニック。いくつかの経験。しかし、結局のところ、すべてのジュニアは可能性があります。彼らが取り組んでいるほぼすべての機能、彼らが前に行ったことがない新しい何かがあります。ジュニアがクラスのプロジェクトに対して単純な状態パターンを実行して「ドア」を開閉したことは確かですが、パターンの実際のアプリケーションは決してありません。

彼/彼女はあなたがどれだけ上手に教えるかと同じくらい良くなるでしょう。もし彼らが「ちょうどそれを手に入れる」ことができたなら、彼らはそもそもジュニアのポジションを取っていただろうと思いますか？

私の経験では、ジュニアは採用され、シニアとほとんど同じ責任を負っていますが、給与が少なく、落ち着くと無視されます。苦いようなら許してください、それは私が原因だからです。

@ jsmorris

私はかつて、前夜にそのような「簡単な」タスクを遅らせて終わらせないために、上級開発者と「アーキテクト」に私とテスター（大学を出た最初の仕事）にメールを送りました。私たちは一日中それをやっていて、それを午後7時に終了すると呼んだ。私はその日の昼食前の午前11時からスラッシングしていて、チームのメンバー全員に少なくとも2度助けを求めていた。

私はチームに返信してccを送信しました。「1か月間、あなたの中でがっかりしました。チームからの助けは得られません。必要に応じて、通りの向こう側のコーヒーショップにいます。私は申し訳ありませんが、12のパラメーター、ほとんどすべてが依存している800行のメソッドをデバッグできませんでした。」

コーヒーショップで1時間涼んだ後、私はオフィスに戻り、がらくたをつかんで立ち去りました。数日後、彼らが私に来るかどうか尋ねるように電話をかけてきました、私はそうするつもりだと言いましたが、おそらく明日は面接を受けました。

「それであなたは辞めましたか？」

ソースリポジトリ：各コミットの前にフックを使用します（SVNのプリコミットフックなど）

そのフックで、メソッドごとに少なくとも1つのユースケースが存在するかどうかを確認します。コミット前フックを介して簡単に実施できるユニットテスト組織の規則を使用します。

統合サーバーですべてをコンパイルし、テストカバレッジツールを使用して定期的にテストカバレッジを確認します。コードのテストカバレッジが100％でない場合は、開発者のコ​​ミットをブロックしてください。コードの100％をカバーするテストケースを送信する必要があります。

自動チェックのみがプロジェクトで適切にスケーリングできます。手ですべてを確認することはできません。

開発者は、テストケースがコードの100％をカバーしているかどうかを確認する手段を持っている必要があります。そうすれば、100％テストされたコードをコミットしない場合、それは彼自身のせいであり、「おっと、ごめん、忘れた」というせいではありません。

覚えておいてください：人々はあなたが期待することをするのではなく、常にあなたが検査することをします。

まず、ここでほとんどの回答者が指摘しているように、テストで男が価値を見出せない場合、それについてできることはあまりなく、男を解雇できないことはすでに指摘しました。しかし、ここでは失敗は許されないので、あなたができるいくつかのことについてはどうでしょうか？

組織の規模が大きく、6人以上の開発者がいる場合は、品質保証部門を設けることを強くお勧めします（たった1人の場合でも）。理想的には、テスター1人と開発者3〜5人の比率が必要です。プログラマーについてのことは...彼らはプログラマーであり、テスターではありません。適切なQAテクニックを正式に教えられたプログラマーにはまだインタビューしていません。

ほとんどの組織は、テストの役割を、新入社員、つまりコードへの露出が最も少ない人に割り当てるという致命的な欠陥を犯します-理想的には、上級開発者はコードの経験があるため、QAの役割に移動する必要があります、そして（うまくいけば）コードのにおいや発生する可能性のある障害点に対する第6の感覚を発達させました。

さらに、間違いを犯したプログラマーは、通常は構文エラーではない（コンパイルで拾われる）ので論理エラーが発生するため、おそらく欠陥を見つけないでしょう。そして、同じロジックが書き込み時に機能します。彼らがコードを書くときのようにテストします。コードを開発した人にそのコードをテストしてもらわないでください。他の誰よりも少ないバグを見つけるでしょう。

あなたのケースでは、リダイレクトされた作業に余裕がある場合は、この新しい人をQAチームの最初のメンバーにします。彼に「実際のソフトウェアテスト：プロセスの改善」を読んでもらいましょう。彼は明らかに彼の新しい役割のトレーニングが必要になるからです。彼が気に入らない場合、彼は終了し、あなたの問題はまだ解決されています。

やや復讐心の低いアプローチは、この人に得意なことをさせて（私はこの人が実際に仕事のプログラミングの部分で有能であるために雇われたと想定しています）、テストを行うために1人または2人のテスターを雇います（大学生は多くの場合、実習または「生協」の条件を持ち、露出が好きで、安価です）

補足：最終的に、QAチームがQAディレクターに報告するか、少なくともソフトウェア開発者マネージャーに報告しないようにします。QAチームが製品を完成させることを主な目的とするマネージャーに報告することは、興味。

組織が6未満の場合、または新しいチームを作成しても問題が解決しない場合は、ペアプログラミング（PP）をお勧めします。私はすべての極端なプログラミング手法を完全に変換しているわけではありませんが、ペアプログラミングを信じています。ただし、ペアのプログラミングチームの両方のメンバーを専用にする必要があります。そうしないと、機能しません。彼らは2つのルールに従う必要があります。インスペクターは画面上で何がコーディングされているかを完全に理解する必要があります。コーダーは、彼が説明できるものだけをコード化できます。「あなたが見る」または「私を信頼する」ことや、手を振ることは許容されません。

あなたのチームがそれを実行できる場合にのみPPをお勧めします。なぜなら、テストのように、エゴに満ちた内向的な2人が一緒に仕事をするのが不快だと感じたとしても、それを応援したり脅したりすることは決してありません。ただし、詳細な関数仕様を作成するか、コードレビューを実行するか、ペアプログラミングを実行するかの選択の間に、通常PPが優先されます。

PPが適切でない場合は、TDDが最善の策ですが、それが文字通り採用されている場合に限られます。テスト駆動開発とは、最初にテストを記述し、テストを実行して実際に失敗することを証明し、次に最も簡単なコードを記述して機能させることを意味します。トレードオフは、あなたが何千ものテストのコレクションを持っていることです（すべきです）。これもコードであり、バグを含む生産コードと同じくらい可能性があります。私は正直なところ、主にこの理由のためにTDDの大ファンではありませんが、テストケースドキュメントよりもテストスクリプトを作成したい多くの開発者にとっては機能します-一部のテストはなしよりも優れています。テストカバレッジの可能性を高め、スクリプトのバグを減らすには、TDDをPPと組み合わせます。

他のすべてが失敗した場合は、プログラマーに誓いのjarと同等のものを用意してください-プログラマーがビルドを壊すたびに、$ 20、$ 50、$ 100（スタッフにとって中程度の痛みを伴うもの）をお気に入りのjarファイルに入れなければなりません（登録済み！）慈善団体。彼らが支払うまで、それらを避けなさい:)

冗談はさておき、プログラマーにテストを書いてもらう最良の方法は、彼にプログラムさせないことです。プログラマーが必要な場合はプログラマーを雇う-テストが必要な場合はテスターを雇う。私は12年前にジュニアプログラマーとしてテストを始めましたが、それが私のキャリアパスになりました。適切に育成され、ソフトウェアを改善する権限と権限を与えられた強固なQA部門は、開発者が最初にソフトウェアを作成するのと同じくらい価値があります。

これは少し無情かもしれませんが、状況を説明する方法は、この男を解雇する必要があるように思えます。あるいは、少なくとも、それを明確にする：（テストを書く含む）自社開発プラクティスに従うことを拒否し、他の人がクリーンアップする必要があること、バギーコードをチェックインは最終的にあなたがトリガーされます。

ジュニアエンジニア/プログラマーがテストスクリプトの設計と実行に多くの時間をかけない主な理由は、ほとんどのCS認定でそれほど必要ではないため、設計パターンなどの他のエンジニアリング分野が大学のプログラムでさらにカバーされているためです。

私の経験では、ジュニアプロフェッショナルを習慣にする最良の方法は、それをプロセスの一部として明示的に含めることです。つまり、反復にかかる時間を見積もるときは、ケースの設計、書き込み、実行の時間をこの時間の見積りに組み込む必要があります。

最後に、テストスクリプトデザインのレビューはデザインレビューの一部である必要があり、実際のコードはコードレビューでレビューする必要があります。これにより、プログラマーは自分が書いたコードの各行を適切にテストする責任があり、上級エンジニアと同僚はコードと書いたテストに関するフィードバックとガイダンスを提供する責任があります。

「デザインがシンプルになることを示す」というコメントに基づいて、皆さんがTDDを実践していることを前提としています。事実の後にコードレビューを行うことはできません。TDDのすべては、それが設計であり、テストの哲学ではないということです。彼がデザインの一部としてテストを記述しなかった場合、特に後輩の開発者からは、事後にテストを記述することから多くの利益を得ることはできません。彼は多くのコーナーケースを見逃してしまうことになり、彼のコードはまだくだらないでしょう。

あなたの最善の策は、非常に忍耐強い上級開発者に同席して、ペアプログラミングを行うことです。そして、彼が学ぶまでそれを続けなさい。または学習しません。その場合、実際の開発者を苛立たせてしまうだけなので、彼をより適切なタスクに再割り当てする必要があります。

誰もが同じレベルの才能や動機を持っているわけではありません。開発チームは、アジャイルチームであっても、「Aチーム」のメンバーと「Bチーム」のメンバーで構成されています。Aチームのメンバーは、ソリューションを設計し、重要なプロダクションコードをすべて記述し、ビジネスオーナーとコミュニケーションをとるメンバーです。Bチームは、構成管理、スクリプトの記述、不完全なバグの修正、保守作業などの処理を行います。すべての作業は、障害の影響が少ない厳密な手順を備えています。