单元测试 – 在进行单元测试时,100%的代码覆盖率是否真的很好?

前端之家收集整理的这篇文章主要介绍了单元测试 – 在进行单元测试时,100%的代码覆盖率是否真的很好?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我总是了解到使用单元测试进行最大程度的代码覆盖是很好的.我还听到像微软这样的大公司的开发人员说他们编写了比可执行代码本身更多的测试代码.

现在,这真的很棒吗?难道它似乎有时像完全没时间损失那样只会使维护变得更加困难吗?

例如,假设我有一个方法DisplayBooks(),它填充数据库中的书籍列表.产品要求表明,如果商店中有超过一百本书,则只能显示一百本.

所以,有了TDD,

>我将首先制作一个单元测试BooksLimit(),它将在数据库中保存200本书,调用DisplayBooks(),然后执行Assert.AreEqual(100,DisplayedBooks.Count).
>然后我会测试它是否失败,
>然后我将通过将结果限制设置为100来更改DisplayBooks()
>最后,我将重新运行测试,看看它是否成功.

那么,直接进入第三步是不是更容易,而且根本不进行BooksLimit()单元测试?并不是更敏捷,当需求将从100个书籍限制改为200个,只更改一个字符,而不是更改测试,运行测试以检查是否失败,更改代码并再次运行测试以检查是否成功?

注意:假设代码已完整记录.否则,有些人可能会说,他们是对的,进行完整的单元测试将有助于理解缺乏文档的代码.事实上,有一个BooksLimit()单元测试将非常清楚地显示有最大数量的书籍要显示,并且这个最大数量是100.进入非单元测试代码会更加困难,因为这样虽然for(int bookIndex = 0; bookIndex< 100; ...或foreach ... if(count> = 100)break;)可以实现limit.

Well,isn’t it much more easier to go directly to the third step,and do never make BooksLimit() unit test at all?

是的…如果你没有花时间编写测试,你将花更少的时间编写测试.您的项目可能需要更长的时间,因为您将花费大量时间进行调试,但也许这更容易向您的经理解释?如果是这样的话……获得一份新工作!测试对提高您对软件的信心至关重要.

当您拥有大量代码时,单元测试可以提供最大的价值.使用几个类调试简单的家庭作业很容易,无需单元测试.一旦你走出这个世界,并且你在数百万行的代码库中工作 – 你就会需要它.你根本无法通过一切单步执行调试器.你根本无法理解一切.你需要知道你依赖于工作的课程.你需要知道是否有人说“我只是要对这种行为进行改变……因为我需要它”,但是他们忘记了还有其他两百种用途依赖于这种行为.单元测试有助于防止这种情况.

关于使维护更难:没有办法!我不能充分利用它.

如果你是唯一曾经参与过你项目的人,那么是的,你可能会想到这一点.但这是疯狂的谈话!尝试在没有单元测试的情况下快速完成30k线路项目.尝试添加需要对代码进行重大更改的功能,而无需进行单元测试.没有信心你没有打破其他工程师的隐含假设.对于维护者(或现有项目的新开发人员),单元测试是关键.我倾向于使用单元测试来获取文档,行为,假设,告诉我何时破坏了某些东西(我认为这是无关的).有时写得不好的API写得不好,可能是改变的噩梦,因为测试会耗费你所有的时间.最终,您将要重构此代码并进行修复,但您的用户也会对此表示感谢 – 因为它,您的API将更容易使用.

关于覆盖范围的说明:

对我来说,这不是100%的测试覆盖率. 100%覆盖率找不到所有错误,考虑使用两个if语句的函数

// Will return a number less than or equal to 3
int Bar(bool cond1,bool cond2) {
  int b;
  if (cond1) {
    b++;
  } else {
    b+=2;
  }

  if (cond2) {
    b+=2;
  } else {
    b++;
  }
}

现在考虑我写一个测试测试:

EXPECT_EQ(3,Bar(true,true));
EXPECT_EQ(3,Bar(false,false));

这是100%的覆盖率.这也是一个不符合合同的功能 – Bar(false,true);失败,因为它返回4.所以“完全覆盖”不是最终目标.

老实说,我会跳过BooksLimit()的测试.它返回一个常量,因此可能不值得花时间编写它们(并且应该在编写DisplayBooks()时进行测试).当某人决定(错误地)从货架尺寸计算该限制时,我可能会感到难过,并且它不再满足我们的要求.我以前被“不值得测试”烧伤了.去年我写了一些代码,我告诉我的同事:“这个类主要是数据,不需要测试”.它有一个方法.它有一个错误.它投入生产.它在半夜打电话给我们.我觉得很蠢.所以我写了测试.然后,我一直在思考什么代码构成“不值得测试”.没有多少.

所以,是的,你可以跳过一些测试. 100%的测试覆盖率非常好,但它并不奇怪意味着您的软件是完美的.这一切都归结为面对变革的信心.

如果我将A类,B类和C类放在一起,并且找到一些不起作用的东西,我是否想花时间调试这三个?不,我想知道A和B已经满足了他们的合同(通过单元测试),我在C级的新代码可能已经破解了.所以我对它进行了单元测试如果我不进行单元测试,我怎么知道它坏了?通过单击某些按钮并尝试新代码?这很好,但还不够.一旦你的程序扩展,就不可能重新运行所有的手动测试来检查一切是否正常.这就是为什么单元测试的人通常也会自动运行他们的测试.告诉我“通过”或“失败”,不要告诉我“输出是……”.

好的,要再写一些测试……

猜你在找的设计模式相关文章