单元测试与验收测试

Question

你是为了一个还是另一个？或两者？

我的理解是单元测试:

• 从开发人员的角度验证系统
• 帮助开发人员练习TDD
• 保持代码模块化
• 帮助检测低粒度级别的错误

验收测试:

• 从业务和QC/QA的角度验证系统
• 往往是高级别的,因为它们通常由不熟悉代码内部工作的人编写

我觉得两者都是必要的.但是,为了最大限度地减少冗余工作,尝试将单元测试纳入验收测试是否是个好主意？换句话说,让后者称之为前者.相反的方向是否有意义？

您对单元测试与验收测试的一般想法是什么,以及如何相互管理它们？

Answer 1

验收和集成测试会告诉您代码是否正常工作; 单元测试告诉你哪里失败了.

如果你已经完成了验收和集成测试,并且它们正在通过,那么你的代码正在实现它应该具备的所有功能,而且它正在工作.很高兴知道(知道它不是很好).但如果它不起作用,验收测试将无法让您深入了解出了什么问题; 因为它测试了许多功能单元,所以它可能是一种鸟瞰失败的观点.这是单元测试闪耀的地方.良好的单元测试可以准确地告诉您出错的地方,以及您的代码的确切部分.很难知道你是否已经编写了足够的单元测试而不是验收测试,但是当你没有相应的失败单元测试的失败验收测试时 - 是时候编写单元测试了.

这完全来自测试的角度.当然,TDD不是(和ATDD不是)关于测试.在推动您的设计方面,验收测试为您提供了一个广泛的路线图("这里就是您想去的地方"),而单元测试将带您到下一个路口("左转").它们在这方面都很有价值,而且它们的价值相互补充.

不要混淆他们; 不要误导他们.特别是单元测试不应该依赖于其他任何东西,并且通过使验收测试依赖于它们来限制单元测试是错误的.当然,他们可以共享一些框架代码,但它们应该是独立的.

Answer 2

但是,为了最大限度地减少冗余工作,尝试将单元测试纳入验收测试是否是个好主意？

没有.

换句话说,让后者[接受]称之为前[单位].相反的方向是否有意义？

不要打扰.

验收测试通常是政治性的.你向他们展示 - 根据他们的直觉 - 决定接受或拒绝.

然后你争论验收测试的有效性.

然后你争论工作范围和下一个版本.

验收测试通常不是技术性的.如果他们是,那么你将有正式的单元测试,那就是那样.

不要试图巧妙地对待政治.接受它.让它发生.

您可以希望验收测试驱动开发(ATDD)导致"验证测试在开发开始之前由整个团队编写并达成一致".但是你必须反映这样一个事实:任何事先写好的东西都是好奇的,最坏的可以谈判.

所有敏捷方法背后的前提是你只能同意获得可释放的东西.之后的一切都是可以谈判的.

所有测试优先(TDD,ATDD或其他任何东西)背后的前提是测试是一项铁腕协议.除非它不是.使用任何TDD(或ATDD)方法,您可以 - 原则上 - 同意测试结果,但您尚未真正同意测试本身.

可能会出现无法轻易编写测试的情况.或者更糟糕的是,根本无法写入.您可能会同意看似可测试的结果,但结果却很难定义.现在怎么办？在您开始开发并了解详细信息之前,这些是您无法了解的.

所有测试都很重要.并且没有特定类型的测试可以是任何其他类型测试的超集或子集.它们总是部分重叠.试图结合以某种方式节省一些工作可能会浪费时间.

更多的测试比其他任何东西都要好.所有测试的结合比试图强制测试之间的子集 - 超集关系更有价值.

Answer 3

单元测试 - 我的特定功能完成它应该做的事情,仅此而已.

验收测试 - 我的应用程序完成它应该做的事情.

示例:用于计算二次函数的根的应用程序.接受a,b和c的输入,返回根x1和x2.这个应用程序是由我写的函数构建的,用于添加两个数字,减去两个数字,乘以两个数字,除以两个数字,并取两个数字的平方根.

单元测试 - 检查我的除法和乘法函数是否正常工作,我的平方根工作正常,加法和减法正常工作.

验收测试 - 检查我的应用程序是否计算二次函数的根.

由于我的整个应用程序是计算根,我不应该有一个单元测试,也计算根,因为没有单独的功能这样做.

Answer 4

综上所述,

• 验收测试确保您正在构建正确的东西
• 单元测试可确保您正确地构建正确的东西