ユニットテストコンテスト
私の雇用主は毎月のユニットテストの日の競争を行っています。丸一日が単体テストの作成に費やされます-明らかに私たちは月を通してより多くのテストを行いますが、これは丸一日です-そして、競争の「勝者」は賞を与えられます。ただし、勝者が誰であるかを判断するのは困難です。
各テストケースにポイントを割り当てていました。したがって、このような単体テストを作成した場合...
for (int i = 0; i < 100; i++) {
assertTrue(i*i, square(i));
}
100ポイントが与えられます。明らかにこれは単純な例ですが、各テストケースに「ポイント」を割り当てる際の問題を示しています。
私たちは主にJava＆Javascriptショップです。そのため、メトリックとしてテストされたコードブランチの数をカウントすることを提案しました。コードカバレッジツール（EclEmmaなど）を介してテストされたブランチを簡単にカウントできます。ただし、Seleniumテストでこれをどのように実行し、Javascriptソースのコードカバレッジを取得するかはわかりません（アイデアはありますか？）
このコンテストの勝者をより適切に決定する方法について何か提案はありますか？
編集
単体テストの書き方、効果的な単体テストの書き方を知っているので、何をテストするかを決めるのに助けは必要ありません。私はこの競争を制御できません-競争は続きます。だから私はそれをより良くするためにいくつかの入力を追加するか、テストを続けます（そうです、私はそれらをゲームします。もちろん私はそれらをゲームします。勝つべき賞があります）
編集
この質問 here は明らかに重複ではありませんが、適切なテストケースを見つける方法に関する有用な情報が含まれていますが、競合を評価するための有用なメトリックは提供されていません。
このコンテストの勝者をより適切に決定する方法について何か提案はありますか？
私にとって意味のある唯一のものは投票することです-すべての開発者は他のすべての開発者のテストに自分のテストを除いていくつかのポイントを割り当てることができます。多分彼はそれが「最も効果的な」ものであると彼が考えるテストのための3ポイント、2番目のための2ポイントと3分の1まで。最もポイントの多いテストが勝利します。特定のテストをだれが書いたかを事前に知らなくても、ポイントの割り当てが行われると、より良い結果が得られる場合があります。
おまけとして、すべてのテストがピアレビューされます。
したがって、このような単体テストを作成した場合...
for (int i = 0; i < 100; i++) { assertTrue(i*i, square(i)); }100ポイントが与えられます。
ループ内のアサーションはほとんど意味がなく、複数のアサート（特にループまたはマップの形式）でのテストは処理が難しいため、この人には0ポイントを与えます（テストが実際に関連するものをテストしていても）。
問題は本質的に、[簡単に]だまされないメトリックを持つことです。アサートの数のみに基づくメトリックは、書かれたLOCごとに開発者に支払うこととまったく同じです。コードを維持するのが巨大で不可能になるPay-by-LOCと同様に、実際の会社のポリシーは、役に立たず、ひどく不適切に書かれたテストにつながります。
アサートの数が無関係である場合、テストの数も無関係です。これは、このような状況で想像できる多くのメトリックス（結合されたものを含む）にも当てはまります。
理想的には、体系的なアプローチを適用します。実際には、これはほとんどのソフトウェア開発会社ではほとんど機能しません。だから私は他のいくつかを提案することができます：
テストにペアレビューを使用して、 1分あたりのWTFの数 メトリックに似たものを持っています。
バグの数に対するこれらのテストの影響を測定します。これにはいくつかの利点があります：
- 公平に見える
- バグレポートとその運命について十分なデータを収集すれば、実際に測定できますが、
- 実際にそれだけの価値があります！
ブランチカバレッジを使用しますが、他のメトリックス（およびレビュー）と組み合わせます。ブランチカバレッジには利点がありますが、より良い成績を得るためだけにCRUDコードをテストすることは、開発者の時間を費やすための最良の方法ではありません。
現時点で適用したい指標をすべて一緒に決定します（このような決定は歓迎されない場合や、一部の企業やチームでは不可能かもしれません）。メトリックを頻繁に確認および変更し、より関連性の高いものを選び、誰もが測定対象と方法を明確に理解するようにします。
私はあなたの雇用主がこのユニットテストの日を組織して、バグを発見するためのインセンティブを与え、より大きなコードカバレッジを達成し、さらに多くのテストを行うことになると思います。
したがって、最も多くのバグを発見した開発者か、コードカバレッジの最大の増加を達成したテストを行った開発者が勝者となるのは当然だと思います。
問題/バグ/欠陥追跡システムで新しいエントリが開かれると、テストによってポイントが獲得されます。その問題のエントリがすでに開いている場合は、カウントされません。また、コメントで提案されているように、独自のコードのバグはカウントされません。他の人のコードのバグだけが数えられるべきです。残念ながら、このアプローチはすぐに満足するものではありません。失敗したすべてのテストが終了し、対応する問題が明らかになるまで数日かかる場合があるためです。また、これは常に機能するとは限りません。システムが成熟すると、テストを追加してバグを発見することが非常にまれになり始める可能性があります。
コードカバレッジの増加は、新しいテストによって表される改善のより客観的な測定を提供する可能性があります。最初に、コードカバレッジ全体を、コンテストの前日に記録する必要があります。次に、各開発者は、他の開発者が作成したテストによるコードカバレッジの増加を考慮せずに、テストのみによるコードカバレッジの増加を何らかの形で示す必要があります。これは、誰かのテストがコミットされる前に、各開発者のマシンに行き、新しいコードカバレッジを記録するレフェリーがおそらく必要になることを意味します。
ちなみに、コードカバレッジを考慮することは、質問で提供した例のようなばかげたことをする代わりに、実際のテストを書く人々に公平な報酬を提供します。