单元测试比赛

我的雇主每月举行一次单元测试日比赛。一整天专门用于编写单元测试-显然，我们每个月都要进行更多测试，但这是一整天-竞赛的“优胜者”将获得奖励。但是，我们发现很难确定谁是赢家。

我们为每个测试用例分配点。因此，如果您编写了这样的单元测试...

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

您将获得100分。显然，这是一个简单的示例，但是它演示了为每个测试用例分配“点”的问题。

我们主要是一家Java＆Javascript商店。因此，我建议将经过测试的代码分支数量作为度量标准。我们可以轻松地通过代码覆盖率工具（例如EclEmma）来计算测试的分支。但是，不确定如何通过Selenium测试以及如何在Javascript源代码覆盖方面做到这一点（有什么想法吗？）

有谁对我们如何更好地确定本次比赛的获胜者有任何建议？

编辑

我知道如何编写单元测试，我知道如何编写有效的单元测试，不需要帮助确定要测试的内容。我无法控制这场比赛-比赛将继续进行。因此，我要么添加一些输入以使其更好，要么继续进行测试游戏（是的，我进行游戏。当然，我进行游戏。有奖品可以赢得）

编辑

这个问题在这里显然是不重复的，但它包含有关如何找到好的测试用例有用的信息，它没有提供任何有用的指标来评估的竞争。

有谁对我们如何更好地确定本次比赛的获胜者有任何建议？

对我来说唯一有意义的是通过投票-每个开发人员都可以为其他每个开发人员的测试分配一些分数（除了他自己的测试之外）。他认为这是“最有效”的测试，满分为3分，第二次为2分，第一至第三分。得分最高的测试获胜。在完成点分配而事先不知道是谁编写特定测试的情况下，它可能会提供更好的结果。

作为奖励，您将获得所有测试同行的审查。

因此，如果您编写了这样的单元测试...

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

您将获得100分。

我会给这个人0分（即使测试正在测试实际上相关的东西），因为循环内的断言意义不大，并且使用多个断言（尤其是以循环或映射的形式）的测试很难使用。

问题本质上是要拥有一个无法轻易被欺骗的指标。专门基于断言数量的度量标准与每个LOC所支付的开发人员费用完全相同。与按LOC方式付款会导致庞大且无法维护代码一样，您的实际公司政策也会导致无用且可能写得不好的测试。

如果断言的数量无关紧要，则测试的数量也无关紧要。对于此类情况，人们可以想象的许多指标（包括组合指标）也是如此。

理想情况下，您将应用系统方法。实际上，这在大多数软件开发公司中几乎不起作用。因此，我可以提出其他建议：

1. 使用结对评论进行测试，并具有类似于每分钟WTF数量的指标。

2. 衡量这些测试随着时间的推移对错误数量的影响。这有几个好处：

   • 看起来还算公平
   • 如果您收集了有关错误报告及其命运的足够数据，则可以实际衡量。
   • 其实是值得的！

3. 使用分支机构覆盖率，但将其与其他指标（以及评论）结合起来。分支机构覆盖有其好处，但是仅仅为了获得更好的等级而测试CRUD代码并不是花费开发人员时间的最佳方法。

4. 共同决定您目前要执行的指标是什么（此类决定在某些公司和团队中可能不受欢迎，甚至是不可能的）。经常检查和更改指标，选择更相关的指标，并确保每个人都清楚地了解要测量的内容和方法。

我想您的雇主组织了这一单元测试日，以激励您发现错误，获得更大的代码覆盖率以及最终进行更多的测试，这些激励将永远有用。

因此，我认为赢家应该是发现最多错误的开发人员，或者是其测试实现的代码覆盖率增长最大的开发人员。

如果测试导致您的问题/错误/缺陷跟踪系统中打开了一个新条目，那么您将获得积分。如果针对该问题的条目已经打开，则不计入。另外，如注释中所建议，您自己的代码中的错误不会计入；只有别人代码中的错误才算在内。不幸的是，这种方法无法立即获得满足，因为可能需要几天的时间才能筛选出所有失败的测试并打开相应的问题。同样，这可能并不总是有效。随着系统的成熟，通过添加测试来发现错误的可能开始变得极为罕见。

代码覆盖率的增加可能会更客观地衡量新测试所代表的改进。首先，必须在比赛前一天记录全部代码覆盖率。然后，每个开发人员将需要以某种方式显示仅由他们的测试导致的代码覆盖率的增加，而不考虑其他开发人员编写的测试导致的代码覆盖率的增加。这意味着您可能需要一名裁判，该裁判将在每个人的测试提交之前前往每个开发人员的计算机并记录新的代码覆盖率。

顺便说一句，考虑代码覆盖范围可以为编写实际测试的人员提供公平的奖励，而不是像您在问题中提供的示例那样做愚蠢的事情。