同僚にユニットテストを書くよう動機付ける方法は？[閉まっている]

私たちは約5年間生産されている大型製品に取り組んでいます。コードベースは動作しています。あまりよくありませんが、機能しています。新機能は実稼働環境に投入され、小さなQAでテストされます。バグは修正されています。しかし、私以外の誰もユニットテストを書いていません。この特別なバグ（テストケース）が二度と発生しないことを保証するために、単体テストを記述してバグを「追跡」する力を使用する人はいません。

私は経営陣と話しました。開発者と話しました。会社全体の全員と話をしました。みんな言う：「そう、もっとユニットテストを書かなければならない！」それは約一年前でした。それ以来、コミット前のコードレビュー（Gerrit）と継続的インテグレーション（Jenkins）の導入を強制しています。

ユニットテストについていくつかの会議を開催し、ユニットテストを書くことの利点も示しました。しかし、誰も興味がないようです。

Q1：同僚に単体テストを書くように動機付けるにはどうすればよいですか？

Q2：個人コードの品質基準を遵守する意欲を維持するにはどうすればよいですか？（時にはイライラすることがあります！）

PS：いくつかのイライラする事実（1年で到達）：

• 単体テスト：1693
• 合計「サンプル単体テスト」：約50
• 完了：1521

編集：私はあまりにも期待していますか？その最初の職場であり、ベストを尽くそうとしています。

編集2：すべての答えに基づいて、私は自分のために小さなチェックリストを作成しました。私はプライベートで2人の開発者と話をしました。

そのうちの1人は、テラスティンが言ったように、彼がユニットテストに本当に不快であると私に言った。彼は「もっとプロフェッショナルになりたい」と言ったが、キックスタートが必要だ。彼はまた、すべての開発者とのユニットテスト会議（約9〜11日）は良かったと言いましたが、あまりにも混雑していました。えー 批評家もいますが、それから学びます。（tdd kataミーティングに関する以下の回答を参照してください！）

もう1人は、単体テストの作成には興味がないと言いました。彼は自分の仕事が給料に十分であると考えています。彼はそれ以上の努力をしたくありません。私は全く言葉を失いました。典型的な9-5「労働者」。

来週は他の開発者と話をします。

素晴らしい回答（これまでのところ）とサポートに感謝します。ほんとうにありがとう！私は多くを学びました、ありがとうございました！

TDDについて話すのはほとんどうまくいかないことに気付きました。人は生の結果を見るのが好きです。「テストを書くことで開発時間を短縮できる」と言うのは本当でしょうが、だれにも納得させるには不十分かもしれません。

私は同様の立場にあり（あなたのように悪くはありません）、人々が私のコードで作業を始めたとき、それ自体が解決しました（注：私のコードは単体テストされ、他の人はそれほど多くありません）。何かが機能しなくなったとき、地元の調査の後の自然なフォローアップは、私に理由を尋ねることでした。それから座って、単体テストを実行し、何が起こったのかを見ました。テストに合格した場合、ほとんどの場合、問題はテストされていない新しいコードにありました。そうでない場合、テストは通常​​、問題を見つけることができました（または、少なくとも正しい方向に私たちを向ける）。バグを修正し、テストが再び行われ、誰もが幸せでした。

簡単に言えば、このようないくつかの状況が発生し、さらに2人の開発者がTDD /テスト愛好家になりました（まだまだまだありますが、有望に見えます）。

アドバイスについては、TDD kataを試してみてください。テストなしとは対照的に、テストファーストアプローチを使用して実装する簡単なタスク。タスクの複雑さに応じて、特にインクリメンタルな変更が必要な場合、テスト以外のアプローチは通常遅くなります。

• ロイの弦計算機
• 銀行OCR

編集：OPのコメントは、彼の処分でさらに強力な議論があることを認識させました- 回帰、別名バグを返します。このような状況は、有益な単体テストがいかに優れているかを示す完璧な例です。数字が好きな人-私が言ったように、「単体テストは良い」と言うことは納得できないかもしれませんが、以下のようなデータを整理することは確かです：

• 機能の実装に費やした時間（テストは記述されていません。これは頻繁に発生するため、このような例を見つけるのは比較的簡単です）
• TDDを使用して機能を実装するための推定時間（またはアプローチ後のテストでさえ、問題ではありません-重要なのは単体​​テストの存在です）
• テストされていないコードとテストされたコードのバグの解決に費やした時間

警告することが1つあります（この移行は明らかですが、注目に値します）：結果のバイアス -テストでバグを見つける唯一の方法がそのバグのテストを書くことである例を選択しないようにしてください。通常、バグが事前に発生することを誰も知りませんが、「Xのテストがあれば、このバグは些細なことになる」と言いたがります。

これらの例の結果は簡単な質問である必要があります。機能Yの開発にx時間を費やすことができた場合、なぜそれを2xで行うことに固執するのでしょうか。

最初に、なぜ彼らがテストを書いていないのかを知る必要があります。

多くの場合、開発スケジュールが厳しいことが理由ですが、それがないと言います。

次の理由は、大規模な既存のテストされていないコードベースでは、おそらくテストの作成が圧倒的だと思われることです。ですから、人間の本質は、それはあまりにも多くのことを考えることですので、私はそれをスキップします。

別の理由としては、テストは良いアイデアだと思う一方で、テストを書いた場所で働いたことがない場合は特に、テストを書く方法に自信がないことが考えられます。

別の強力な可能性は、アイデアにリップサービスを提供しているにもかかわらず、より多くの仕事に価値がないことです。

では、さまざまな理由にどのように対処しますか？

理由1は単純で、開発時間を節約する方法の例を示します。

理由2-1年間に書いたテストの数と、それがカバーするコードベースの割合を示します。計算を実行して、来年のこの時点でさらにテストを行うことができるかどうかを示します。日々の小さな進歩が実際に積み重なっていることがわかると、全体のアイデアはそれほど圧倒的ではありません。システムからデータを引き出すことができる場合は、コードのテストされていない部分で繰り返し発生したバグの数と、単体テストでコードに表示される繰り返しのバグの数を示します。

理由3は、単に表示するだけでなくトレーニングです。トレーニングクラスでテストを作成させます。

理由4、これが問題の核心です。最初に、複数回戻ってきたバグの1つである問題点を選択します。それが入ってきたら、今度は経営陣に、このアイテムの単体テストがあれば、悪いペニーのように戻ってこないことを提案する時です。

理由4に対処する別の方法は、管理者にプロセスの一部としてもらい、テストもコードレビューに合格しない限り、コードはコードレビューに合格しないことです。これらの問題のいずれかの直後、またはできれば数日後にいくつかの問題を抱えた直後に、これをポリシーにすることをお勧めします。

開発者として私たちは自己管理（LOL）すると思いますが、意欲的な人は、管理が彼らに気を付けるべきことを彼らに強調することを気にし、自己管理を実際に行う専門家はすでにテストを書いています。製品を改善するためにプロであることやベストプラクティスを実行することも、昇進する（または解雇されない）ことをマネージャーに印象付けることも気にしない場合は、これが適切な場所であるかどうかを検討することができます。経営陣にベストプラクティスを気にかけられない場合は、ずっと苦労して戦います。これがあなたにとって適切な企業文化であるかどうかを評価するかもしれません。すべての職場には問題があります（そして、逃げることが常に答えとは限りません）が、この場所はあなたのプロ意識のレベルに合っていないようです。

まず、TDDの利点を示すことから始めます。単体テストの利点を紹介してください。

通常の人間として、開発者は利益に動機付けられています。彼らは、より多くの仕事を生み出すだけのことをしたくありません。単体テストは作業量が少ないことを意味します。友達ともっと出かけることを意味します。毎晩午後11時までコーディングする必要がないため、より楽しい時間を過ごすことができます。それは、安心して休暇をとることを意味します。

TDDの最大の利点の1つは、プログラムをより良いデザインにリファクタリングしたり、何かの名前を変更したりできることです...そしてそのデザインがテストに違反しない限り、変更を100％確信できるということです何も壊さなかった。

TDDのもう1つの優れた事例は、レガシーコードの単体テストの作成です。これは、悪のリファクタリングを開始する最良の方法の1つです。長い目で見れば、これはコードベースの知識を向上させ、その長所と欠点を理解し、コード内のハードコードされたビジネスロジックを見つけ、品質を改善するための良いスタートを切るのに役立ちます！

さらに読むための参考文献：

• ユニットテストを書くべき理由
• 動機の可視性、および単体テスト
• Roy Osheroveによると、単体テストの技術

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

私は少し前にジェフ・アトウッドの記事からそのリンクをブックマークしたと思う[編集：うん、ここにある]。古いが関連性があります。これらの利点や他の回答で説明されている疑いの余地があるため、プログラマは自分のやる気を引き出すことができるはずです！それは彼らがより効率的に働くことを可能にし、したがって彼らの仕事を少し楽にします。誰がそれを望んでいないのですか？

2番目の質問に関しては、所有者の意識とコード品質基準に対する誇りが、あなたにそれらを順守させてくれるはずです。そのような標準を作成することで何を達成したいのかを考え、誰がそれらから利益を得るのかを考えてください。私の個人的なコード標準もイライラする可能性がありますが、それを実装することで世界/会社/チームに有利に働いているといつも感じています。だから私はあなたがやりすぎているとは思わない-結果は場所によって異なるが、少なくともあなたは努力している。

これは例によって鉛の大きなケースのようです。

あなたが戦っている人間の本質には、2つの固有の側面があります。

• クリエイティブな人はプロセスが好きではありません。
• ほとんどの人は、品質に関する外部からの否定的な判断を好みません。

講義、経営陣の宣言、または論理でこれと戦うことは非常に困難です。あなたは人間性の別の側面を利用して勝たなければなりません。

• 人々は最高の従業員の行動をまねる

最高の従業員がTDDを使用し、それが機能する場合、プロセスは拡大します。そうでない場合、それはしません。誰かを説得する必要がある場合、それはトップ1または2の従業員です。

彼らに聞いてください。

あなたは人々は言われたと言い、彼らはもっとテストを書くべきであることに同意します。なぜそうではないのですか？

それは単純な動機の問題ではないかもしれません（多くの場合そうではありません）。彼らはそれらを忘れるかもしれません。彼らは時間のプレッシャーの下で感じるかもしれません。彼らは良いテストを書く方法を知らないかもしれません。彼らはあなたがそれをする必要がないほど優秀だと思うかもしれません。根本原因を知ることは、問題をよりよく解決するのに役立ちます。

単体テストは自分自身を売ることだと思うでしょう。あなたの会社がどのように機能するかはわかりませんが、生産ロールアウト中に問題が発生した場合、修正されるまで問題を解決します。日曜日の午前2時に発生するかどうかは関係ありません。これは私たちにとって非常にまれですが、そうなるとひどくなります。

自動テストを簡単に見つけることができるいくつかの主要な問題を修正するために、深夜に何回起きなければならないかを尋ねることから始めます。それは自動テストがすべてを修正すると言うことではありませんが、それはそれを減らすのに役立つはずです。

2番目の大きな売り手はQAサイクルです。私の会社でTDDを開始する前に、毎週テストのために新しいリリースをQAにプッシュしていました。それらはそのリリースから大量のバグを作成し、それらのバグを修正して別のリリースをプッシュします。完了するまで繰り返します。TDDで最初に行ったプロジェクトでは、数週間後までQAへのプッシュアウトは必要ありませんでした。また、見つかったバグの数は非常に少ないです。同様のプロジェクトと比較して10％。とにかくあなたのチームのためにそれらの統計をコンパイルする必要がありますか？

もう1つの大きなセールスポイントは、TDDが採用された後のコードの外観です。テストしやすくしたかったため、読みやすくなりました。単体テスト用に記述されたコードと記述されていないコードの比較を表示します。

最後に、自信を持ってコードをリファクタリングできる方法を示します。

テストを書く気にならないときは、これらすべてを念頭に置いてください。:)

HLGEMの答え、特にこのセクションを拡張したいと思います。

次の理由は、大規模な既存のテストされていないコードベースでは、おそらくテストの作成が圧倒的だと思われることです。ですから、人間の本質は、それはあまりにも多くのことを考えることですので、私はそれをスキップします。

テストを書くつもりで書いたコードは、テストを書くつもりで書いたコードよりもはるかに優れたコードであることがわかりました。自分自身を求めて、私はこの機能をテストしますどのように？各機能のより良い設計を強制します。（グローバルまたはセミグローバルデータへの依存度の低下、計算から分離されたIO、関数の実行は1つのみ、一貫性のあるエラー処理など）

テストを念頭に置いて書かれていない古いコードにテストをしようとすると、イライラすることはありません。

私はいくつかのテクニックを使用しました：

a）自動ビルドをセットアップします。誰かがあなたがテストしたものを壊すとき、テストがそれをどのように検出したか、そしてバグがどれほど悪いかを彼らに示してください。

b）テストで複雑なプロジェクトを行います（運転します）。これにより、そのプロジェクトに存在するバグの数がわかります。完璧に機能し始めた1つの複雑なサーバーインタラクションプロジェクトがありました。QAに失敗することはなく、すべての統合テストは100％スムーズに進みました。そのシステムは非常に安定したものとして知られるようになり、全体的な管理者はそれに満足しています。これらの状況で行うことは、単体テストがそれをどのように可能にするかを示すことです。

c）一度に1人ずつ引き込みます。あなたに耳を傾ける人。バグに取り組み、テストがどのように深く困難な問題を明らかにするかを示します。これは役立ちます。決して簡単なことではありません。しかし、ファンを獲得すると、彼は助けてくれるだけです。ドミノ効果です。

プロセスでユニットテストを焼きます。本番環境でバグが明らかになりすぎてユニットテストでキャッチできない場合、この男が責任を負います。作成する各テストを作成するために人々を割り当てます。ランダムにケースを選択し、毎週いくつかのケースの実行を監視します。単体テストを行うことで、人々は要件について尋ね、最終的に要件を開発に結び付け、できれば必要で動作するソフトウェアを開発します:)