我如何真正单元测试代码?

21 unit-testing

我正在阅读Joel Test 2010,它让我想起了我对单元测试的一个问题.

我如何真正进行单元测试?我没有单元测试功能?只有全班?如果我有15个<20行的课程怎么办?我是否应该为每个类别编写一个35行单元测试,将15*20行写入15*(20 + 35)行(从300到825,将近3倍的代码).

如果一个类只被模块中的其他两个类使用,我应该对它进行单元测试,还是对其他两个类的测试是否足够?如果他们都是<30行代码应该怎么办?

如果我编写代码来转储数据,我永远不需要阅读它,例如使用另一个应用程序.另一个应用程序不是命令行,或者它无法验证数据是否良好.我还需要进行单元测试吗?

如果应用程序是实用程序且总数小于500行代码,该怎么办?或者是使用了一周,将在未来使用,但总是需要重新配置,因为它是为快速批量处理和每一个项目都需要调整,因为欲望输出不变.(我想说那里有没有办法解决它,为正当的理由,它会永远进行调整)我的单元测试它如果又如何?(也许我们不关心我们是否打破了过去使用的功能,但现在或将来都没有).

等等

我认为这应该是一个维基.也许人们想说出他们应该单位测试(或不应该)的确切内容?也许书籍链接很好.我尝试了一个,但它从未澄清应该进行单元测试的内容,只是编写单元测试和解决方案的问题.


此外,如果班是为了只在该项目(由设计,规格或任何其他原因)和类心不是单独有用的(可以说是产生使用返回HTML准备评论数据的HTML)我真的需要测试它?通过检查当我的项目没有使用空注释时,所有公共函数是否允许空注释对象.它的那些东西让我想知道我是否在测试错误的代码.在项目中还有大量的课程.它是临界一次性或不是非常有用的单独代码困扰我.

Owe*_* S. 27

这就是我所听到的,无论你是否以这种方式表达它:一连串的问题和借口,为什么单元测试可能不适用于你的代码.换句话说:"我看不出我将从单元测试中得到什么,而且他们写的很麻烦;也许他们不适合我?"

你知道吗?你或许是正确的.单元测试不是灵丹妙药.单元测试无法涵盖大量广泛的测试.

但是,我认为你错误地估计了维护成本,以及代码中可能出现的问题.所以这是我的想法:

  • 我应该测试小班吗?是的,如果该课程中有些东西可能会破坏.
  • 我应该测试功能吗?是的,如果此功能中的某些内容可能会中断.你为什么不呢?或者您是否关注它是否被视为一个单位?这只是对名称的争论,不应该对你是否应该为它编写单元测试有任何影响!但是根据我的经验,将方法或功能描述为被测单元是很常见的.
  • 如果一个类被其他两个类使用,我应该对它进行单元测试吗?是的,如果有什么东西可能会破坏那个班级.我应该单独测试吗?这样做的好处是能够将破坏直接隔离到共享类,而不是通过使用类来查看它们是否已损坏或是否存在其依赖项.
  • 如果另一个程序读取它,我应该测试我班级的数据输出吗? 好吧,特别是如果其他程序是第三方程序!这是单元测试的一个很好的应用(或者可能是系统测试,取决于测试中涉及的隔离):向您自己证明您输出的数据正是您认为应该输出的数据.我想你会发现它有能力无法简化支持调用.(但请注意,它不能替代该客户端的良好验收测试.)
  • 我应该测试一次性代码吗?有可能.追求TDD策略会更快地将您的一次性代码推出门吗?它可能.具有可以适应新约束的经过单元测试的可靠块,是否会减少抛出代码的需要?也许.
  • 我应该测试不断变化的代码吗?是.只需确保所有适用的测试都是最新的并通过!毕竟,不断变化的代码特别容易出错,并且实现安全更改是单元测试的另一个好处.此外,它可能会给您的不变代码带来尽可能强大的负担,以实现这种变化速度.而且你知道如何让自己说服一段代码是否健壮......
  • 我应该测试不再需要的功能吗?不,您可以删除测试,也可能删除代码(测试以确保您在此过程中没有破坏任何内容!).不要让单元测试腐烂,特别是如果测试不再起作用或运行,或者组织中的人员将远离单元测试并且您将失去优势.我看到过这种情况.它不漂亮.
  • 我是否应该测试我的项目未使用的代码,即使它是在我的项目上下文中编写的?取决于项目的可交付成果,以及项目的优先级.但是你确定项目之外没有人会使用它吗?如果他们不这样做,而你却不是,也许这只是死代码,在这种情况下见上文.从我的角度来看,如果我的测试没有涵盖所有重要功能,项目是否使用了所有功能,我觉得我没有完成一个完整的课程.我喜欢那些感觉完整的课程,但我一直关注不要过度设计一些我不需要的东西.如果我把一些东西放在一个类中,那么,我打算使用它,因此我想确保它有效.它'

  • 重新测试数据输出:应该不需要编写重型解串器,只需创建一个"黄金输出"文件,并确保输出与它匹配,使用diff或您选择的工具. (2认同)

Mar*_*tos 17

不要注意计算代码行.编写尽可能多的测试代码,以说服自己每个关键功能都经过全面测试.作为一个极端的例子,SQLite项目有一个测试:源代码比率超过600:1.我在这里使用了"极端"一词; 正在进行的大量测试可能是SQLite占领世界的主要原因.