ユニットテストコンテスト

私の雇用主は、毎月の単体テストの日の競争を実施しています。1日は単体テストの作成に専念します。明らかに、1か月を通してより多くのテストを行いますが、これは1日であり、コンテストの「勝者」には賞が与えられます。しかし、勝者が誰であるかを判断するのは難しいと感じています。

各テストケースにポイントを割り当てていました。したがって、このような単体テストを作成した場合...

for (int i = 0; i < 100; i++) {
  assertTrue(i*i, square(i));
}

100ポイントが与えられます。明らかにこれは単純な例ですが、各テストケースに「ポイント」を割り当てる際の問題を示しています。

私たちは主にJavaとJavascriptのショップです。そのため、テストしたコードブランチの数をメトリックとしてカウントすることをお勧めします。コードカバレッジツール（EclEmmaなど）を使用して、テストしたブランチを簡単にカウントできます。ただし、Seleniumテストでこれをどのように行い、Javascriptソースのコードカバレッジを取得するのかわかりません（アイデアはありますか？）

このコンペティションの勝者をどのように決定できるかについての提案はありますか？

編集

私は単体テストの書き方を知っています。効果的な単体テストの書き方を知っています。何をテストするか決めるのに助けは必要ありません。私はこの競争をコントロールすることはできません。競争は続きます。それで、私はそれを改善するためにいくつかの入力を追加するか、テストをゲームで続けます（はい、私はそれらをゲームします。もちろんそれらをゲームします。賞品があります）

編集

この質問ここでは、明らかに重複していない、それは良いテストケースを見つける方法に関する有用な情報が含まれているものの、それが競争を評価するための任意の有用な指標を提供していません。

このコンペティションの勝者をどのように決定できるかについての提案はありますか？

私にとって理にかなっている唯一のことは、投票によることです-すべての開発者は、他のすべての開発者のテストに自分のテストを除くいくつかのポイントを割り当てることができます。多分、彼はそれが「最も効果的な」テストだと考えているテストで3ポイント、2番目と2番目のポイントが2ポイントです。最もポイントの多いテストが勝ちです。特定のテストを誰が書いたのかを事前に知らずにポイントの割り当てを行った場合、より良い結果が得られる場合があります。

ボーナスとして、すべてのテストのピアレビューを取得できます。

したがって、このような単体テストを作成した場合...

for (int i = 0; i < 100; i++) {
 assertTrue(i*i, square(i));
}

100ポイントが与えられます。

ループ内のアサーションはほとんど意味がなく、複数のアサーション（特にループまたはマップの形式）でのテストは作業が難しいため、この人に0ポイントを与えます（テストが実際に関連する何かをテストしている場合でも）。

問題は本質的に、[簡単に] cheされないメトリックを持っていることです。アサートの数のみに基づくメトリックは、書かれたLOCごとに開発者に支払うこととまったく同じです。Pay-by-LOCの場合と同様に、コードを維持するのが巨大で不可能になりますが、実際の会社のポリシーは、役に立たない、場合によっては不適切に書かれたテストにつながります。

アサートの数が関係ない場合、テストの数も関係ありません。これは、この種の状況で想像できる多くのメトリック（結合されたものを含む）にも当てはまります。

理想的には、体系的なアプローチを適用します。実際には、これはほとんどのソフトウェア開発会社ではほとんど機能しません。だから私はいくつかの他のことを提案することができます：

1. テストにペアレビューを使用し、1分あたりのWTFメトリックの数に似たものを使用します。

2. バグの数に対するこれらのテストの経時的な影響を測定します。これにはいくつかの利点があります。

   • 公平に思える、
   • バグレポートとその運命に関する十分なデータを収集すれば、実際に測定できますが、
   • 実際に価値があります！

3. ブランチカバレッジを使用しますが、他のメトリック（およびレビュー）と組み合わせます。ブランチカバレッジには利点がありますが、CRUDコードをテストしてより良いグレードを取得することは、開発者の時間を費やす最良の方法ではありません。

4. 現時点で適用する指標を一緒に決定します（そのような決定は歓迎されないか、一部の企業やチームでは不可能な場合もあります）。メトリックを頻繁に確認および変更し、より関連性の高いものを選択し、誰もが何をどのように測定するかを明確に理解するようにします。

バグを発見し、より多くのコードカバレッジを達成し、より多くのテストを行うことで人々にインセンティブを与えるために、あなたの雇用主はこのユニットテストの日を組織すると思います。

したがって、勝者は、最も多くのバグを見つける開発者、またはコードカバレッジの最大の増加を達成したテストの開発者であることが理にかなっていると思います。

問題/バグ/欠陥追跡システムで新しいエントリが開かれた場合、テストはポイントを獲得します。その問題のエントリが既に開いている場合、カウントされません。また、コメントで示唆されているように、独自のコードのバグはカウントされません。他の人のコードのバグだけがカウントされるべきです。残念ながら、この方法では、すべての失敗したテストがふるいにかけられ、対応する問題が解決されるまで数日かかるため、すぐに満足することはできません。また、これは常に機能するとは限りません。システムが成熟するにつれて、テストを追加してバグを発見することが非常にまれになり始める可能性があります。

コードカバレッジの増加は、新しいテストによって表される改善のより客観的な測定を提供する可能性があります。まず、競技会の前日に全コードカバレッジを記録する必要があります。次に、各開発者は、他の開発者によって作成されたテストによるコードカバレッジの増加を考慮せずに、テストのみから生じるコードカバレッジの増加を何らかの形で示す必要があります。これは、おそらく、各開発者のマシンに行き、誰かのテストがコミットされる前に新しいコードカバレッジを記録する審判が必要になることを意味します。

ちなみに、コードカバレッジを考慮に入れると、質問で提供した例のようなばかげたことをする代わりに、実際のテストを書く人に公平な報酬が与えられます。