これは確かに、単体テストが優れていることを前提としています。私たちのプロジェクトにはある程度の単体テストがありますが、せいぜい一貫性がありません。
形式化された単体テストは良いことであり、それを必須にすることが私たちが取り組んでいる「大規模な」プロジェクトにとって本当に最善の利益になることを皆に納得させるために、あなたが使用した、またはあなたと一緒に使用した最も説得力のある方法は何ですか. 私は開発者ではありませんが、品質保証の担当者であり、提供される作業の品質を改善して、テストの準備が整っていることを確認したいと考えています。
形式化された単体テストによって、私は単に話しているだけです
非常に説得力のある方法は、チーム/会社が何をしているかに関係なく、形式化された単体テストを自分で行うことです。特にこの種の練習に慣れていない場合は、これには余分な労力がかかる場合があります。
自分のコードが他の開発者よりも優れており、生産性が高いことを示すことができれば、開発者はその理由を知りたがるでしょう。次に、お気に入りの単体テスト メソッドを提供します。
仲間の開発者を説得したら、一緒に経営陣を説得します。
すべてのビルドでMavenとSurefireおよびCoberturaプラグインを使用しています。実際のテスト ケースは、JUnit、DbUnit、およびEasyMockで作成されます。
単体テストの特定 私はテスト駆動開発に従うようにしていますが、正直に言うと、通常はほんの一握りのテスト ケースに対してだけ行い、後で戻ってエッジ ケースと例外ケースのテストを作成します。
テスト データの識別 DbUnit は、単体テスト用のテスト データを読み込むのに最適です。
テスト ケース の作成 JUnit を使用してテスト ケースを作成します。私は自己文書化テスト ケースを作成しようとしていますが、Javadocs を使用して、明らかでないことをコメントします。
Tracking & Making The Results Available I integrate the unit testing into my Maven build cycle using the Surefire plugin and I use the Corbertura plugin to measure the coverage achieved by those tests. I always generate and publish a web-site including the Surefire and Cobertura reports as part of my daily build so I can see what tests failed/passed.
私を納得させたのは、3 回連続してリリースして 3 回もバグを修正できたときです。些細な間違いがクライアントに渡された後、常にそれを修正していなかったときに、プログラマーとしての生産性がどれだけ向上したかを認識し、同僚のコードが彼らが主張したことを実行するという漠然とした気持ちを抱くことができたとき、私は改宗者。
私がメインフレームで COBOL 開発を行っていた当時、私が働いていたいくつかの企業ではこれを宗教的に行っていましたが、環境がそれを強制したため、それが物事を行う方法として受け入れられました。それはその時代の非常に典型的なスキームだったと思います。おそらくいくつかの理由があなたに当てはまるかもしれません:-
ほとんどのメインフレーム環境と同様に、開発、品質保証、および生産という 3 つの領域がありました。プログラマーはそこで開発を行い、そこで単体テストを行い、サインオフして満足すると、単体は (テストと結果のドキュメントと共に) QA 環境に移行され、専任の QA スタッフによるシステム テストが行われました。開発から QA への移行は、一夜にして行われた正式なステップでした。QA が終了すると、コードは本番環境に移行されました。バグはほとんどありませんでした。
単体テストを適切に行う動機は、それを行わずに QA スタッフがバグを発見した場合、その作業を行っていないことは明らかだったからです。したがって、あなたの評判は、あなたがどれだけ厳格であったかにかかっていました。もちろん、ほとんどの人は時折バグに遭遇することになりますが、常に安定したテスト済みコードを作成したコーダーはすぐにスターの評判を得て、バグのあるコードを作成した人も注目されました。推進力は常にゲームを向上させることであり、その結果、最初にバグのないコードを提供することを推進する文化が生まれました。
該当箇所の抽出 -
環境は異なると思いますが、プリンシパルは翻訳可能かもしれません。
教育および/または認定。
チーム メンバーに、テストの分野で正式なトレーニングを提供します。認定試験を伴う場合もあります (チーム メンバーと、認定に対するあなた自身の態度によって異なります)。そうすれば、テストをより高いレベルに引き上げることができ、チーム メンバーはテストに対してより専門的な態度を取る可能性が高くなります。
例によって最善の方法である場合もあります。また、物事がテストされているとき、特定のことが起こらないことを人々に思い出させることにも気づきました。次に誰かに何かを書くように頼まれたら、とにかくテストをしてください。最終的には、コードを簡単に変更して、それがまだ機能することを知っていることを同僚がうらやましく思うでしょう。
管理に関しては、テスト対象ではないコードベース X に変更を加える必要があるときに発生する核爆発により、どれだけの時間が浪費されるかを強調する必要があります。
多くの開発者は、システム全体で動作を維持していることを確認せずに、どれだけリファクタリングを行っているかを認識していません。私の意見では、これが単体テストと TDD の最大の利点です。
唯一の確実性は変化です。テスト対象外のコードを変更する場合、開発者は可能な限りすべての動作上の副作用を認識する必要があります。現実には、すべての順列を読み取ることができると考えているコーダーは、明らかに壊れるものが何もなくなるまで、試行錯誤の骨の折れるプロセスによってそうしています。この時点で、彼らはチェックインします。
実用的なプログラマーは、自分が完璧ではなく、すべてを知っているわけではなく、テストは、リファクタリングの綱渡りを迅速かつ安全に行うためのセーフティ ネットのようなものであることを認識しています。
グリーンフィールド コードのテストをいつ作成するかについては、可能な限り推奨する必要があります。システムに必要な動作を定義するのに時間を費やし、最初にテストを作成して、それらのより高いレベルの構造を表現します。単体テストは、考えが具体化するときに発生する可能性があります。
お役に立てれば。
納得させることと要求することには大きな違いがあります。
同僚にそれらを書くように説得する方法を見つけたら、それはすばらしいことです。ただし、形式化されたルールをいくつか作成し、単体テストを作成するように要求すると、これを克服する方法が見つかります。その結果、何の価値もない一連の単体テストが得られます。利用可能なすべての単一クラスの単体テストがあり、セッターとゲッターをテストします。
ルールを作成して適用する前に、よく考えてください。開発者はそれらを克服するのが得意です。
それらをたくさん書いて、単体テストによって生産性とコードの品質が向上したことを実証してください。なんらかの証拠がなければ、その価値があるとは信じられないことがあります。
私のソフトウェア チームでは、テストを作成して追跡する時間を確保するために、これらの問題について小さなビジネス ケースを作成し、経営陣に提示する傾向があります。テストにかかる時間は、危機の時期が来てすべてが順調に進んだときのために十分に補われていることを説明します. また、単体テストの追跡を一元化するために、Hudson ビルド サーバーをセットアップしました。これにより、開発者は失敗したテストを追跡したり、再発する問題を発見したりすることが非常に簡単になります。
この質問をしてから 2 年経った今、予想外の答えの 1 つが、新しい SDLC に移行することが必要だったというものであることがわかりました。5 年前、私たちは最初の正式な SDLC を設立しました。状況は改善されましたが、自動化などの重要な機能がいくつか取り残されていました。現在、テナントの 1 つが自動化されている新しい SDLC (新しい管理下) を確立する過程にあります。自動化された単体テストだけでなく、自動化された機能テスト。
教訓は、私が小さすぎて考えていたことだと思います。ソフトウェアの作成方法を変更する場合は、それに慣れていない場合は、漸進的な変更を提案するのではなく、「完全に独り占め」して大幅な変更を加えてください。
あなたのチームや他の開発者に、彼らはアマチュアではなくプロであることを思い出させてください。私のために働いた！
また、これは最近の業界標準です。単体テストの経験がなければ、将来の雇用主にとって、従業員としての価値も価値も低くなります。
初めての場合は、先に進んでそれらを作成し、その価値があることを人々に示す必要があります. 私は 3 つのプロジェクトで、それが人々を説得する唯一の方法であることを発見しました。コーディングをしない一部の人々 (たとえば、ジュニア プロジェクト マネージャー) は、直接目の当たりにするまでその価値を理解できません。
チーム リーダーとして、私のプログラマーが作業しているすべてのモジュールに対して単体テストを実行していることを確認するのは私の責任です。現時点では、どう説得するかは問題ではなく、必要なのだと思います。大規模なプロジェクトではなく、常にです。単体テストは、保守する必要のあるものを本番環境に置くことに対する防御の最前線です。ユニットとシステムの完全なテストが行われていない製品が生産に投入された場合、それはあなたを悩ませます。これをサポートするために私たちがここに持っているポリシーの1つは、それが本番環境で失敗したり、問題を引き起こしたりした場合、そのモジュールのコーディングとテストを担当するプログラマーが問題を処理し、クリーンアップを行う必要があるということです。など、それだけでもかなりのモチベーションになります。
もう一つは、プライドについてです。私は約 75 人のコーダーがいる職場で働いています。これはある基準からすれば大規模ですが、私たち全員がお互いを知るには十分な規模です。また、お互いが何に取り組んでいるかを把握できるほど小さいので、本番環境に移行するときに異常終了や障害などを認識できます。注意が必要な場合は、ユニットとシステムのテストを行って、何かを移行する可能性を確認してください。障害を起こさずに生産に移行することが大幅に増加します。何かを本番環境に移行してそれを認識できない場合、1、2 時間かかる場合がありますが、混乱しないことには大きな見返りがあります。プロジェクトを引っ越すと、廊下でお祝いの言葉を聞くのは本当にうれしいことです。