单元测试验收测试?

如果你把软件开发想象成一个汽车生产厂,那么写软件的行为就像开发一辆新车。每个组件都是单独测试的,因为它是新的。以前从来没有这样做过。(如果有的话,你可以找以前做过的人,或者直接买下来。)

你的构建系统,构建了你的软件,也测试了它,就像传送带——一辆车接一辆车的制造过程。汽车制造商通常会考虑如何将新部件的生产自动化,并在生产新部件的过程中测试他们的汽车,你可以打赌他们也会测试生产这些汽车的机器。

所以,是的,对我来说,单元测试您的验收测试似乎非常好,特别是如果它帮助您更快地进行并使事情更容易更改。

一个朋友非常热衷于这样一个概念:验收测试告诉你代码是否被破坏,而单元测试告诉你代码是否被破坏。 在哪里? 它被破坏了;这些是互补的和有价值的信息。验收测试更好地让你知道什么时候完成了。

但是要完成这项工作,您需要一路上的所有部分;您需要它们工作,这就是单元测试所擅长的。首先完成测试,它们还将引导您进行更好的设计(不仅仅是有效的代码)。一个好的方法是写一个大局的验收测试,然后对自己说:“当这通过了,我就完成了。”然后努力使它通过,工作TDD:为下一个小的功能编写一个小的单元测试,你需要使它通过;编写代码使它通过;重构;重复。随着您的进展,不时地运行;您可能会在稍后的测试中发现它失败。如前所述,当它通过时,你就完成了。

我认为单元测试验收测试本身没有多大意义。但是单元测试它的助手类——实际上,首先编写它们测试——是一个非常好的方法。你很可能会找到一些方法,你写的“只是为了测试”工作的方式到生产代码-即使你不,你仍然想知道你的ATS使用的代码是正确的。

如果at足够简单,那么“测试测试代码,代码测试测试测试”这句古老的格言可能就足够了——当测试失败时,要么是因为代码错误,要么是因为测试错误,并且应该很容易找出哪一个。但是,当测试很复杂时,最好也对其基础进行良好的测试。

使用单元测试框架(如JUnit)编写验收测试(或集成测试)没有任何错误。人们不喜欢称他们为“单元测试”,原因有很多。对我来说,主要的原因是集成/验收测试不会每次运行一次检查变更(太长或/和没有合适的环境)。

您的助手类是包含“测试基础结构代码”的相当标准的东西。它们不属于任何其他地方,只属于测试代码。你可以选择是否测试它们。但是没有它们,你的测试在大系统中是不可行的。

所以,你的选择是2或者根本没有测试。重构基础结构代码以使其更加透明和简单并没有错。

您的选项2就是我要做的:首先编写助手类测试-听起来您知道它们应该做什么。

这些测试都是测试,尽管辅助类不是严格的测试,但是它们不会被您的主代码引用,只是测试,所以它们属于测试。也许它们可以在常规测试的单独包/名称空间中。