单元测试验收测试？

Question

我目前正在进行一些验收测试，这将有助于推动我即将开展的计划的设计。一切似乎都很好，除了我已经意识到验收测试有点复杂，也就是说，尽管它们在概念上很简单，但它们需要相当多的棘手代码才能运行。我需要为我的验收测试制作一些“帮助”类。

我的问题是如何发展它们：

1. 对我的验收测试进行单元测试（这看起来很奇怪 - 有没有人做过这样的事情？）
2. 为这些帮助类进行单元测试。在完成了这些帮助类的所有代码之后，我可以通过并开始研究我的系统的真实单元测试。使用这种方法时，你会把辅助类放在哪里？在测试项目或实际项目中？它们不一定依赖于测试/模拟框架。
3. 还有其他想法吗？

Answer 1

朋友非常热衷于接受测试会告诉您代码是否损坏，而单元测试会告诉您 它已被破坏;这些是互补和有价值的信息。验收测试最好让你知道什么时候完成。

但要完成，你需要一路上的所有作品;你需要他们工作，这就是单元测试的优点。完成测试 - 首先，他们还将引导您更好地设计（不仅仅是有效的代码）。一个好的方法是写一个大画面的验收测试，并对自己说：“当这个过去时，我已经完成了。”然后努力使其通过，工作TDD：编写一个小单元测试，以获得使AT通过所需的下一小部分功能;编写代码使其通过;重构;重复。随着你的进步，不时运行AT;你可能会发现它在以后和测试后期失败了。并且，如上所述，当它过去时，你已经完成了。

我认为单元测试验收测试本身并没有多大意义。但单元测试其辅助类 - 实际上，将它们编写为测试优先 - 是一个非常好的方法。您可能会发现一些“仅供测试”编写的方法，这些方法正在进入生产代码中 - 即使您不这样做，您仍然希望知道您的AT使用的代码是正常的。

如果你的AT足够简单，那么“测试代码，代码测试代码”的古老格言可能就足够了 - 当你有一个失败的测试时，它要么是因为代码错了，要么是因为测试这是错误的，它应该很容易找出哪个。但是当测试很复杂时，最好还是对它的基础进行良好的测试。

Answer 2

使用单元测试框架（如JUnit）编写验收测试（或集成测试）没有任何问题。由于种种原因，人们不喜欢称他们为“单元测试”。对我来说，主要原因是每次检查更改（太长或/和没有适当的环境）时，集成/验收测试都不会运行。

您的帮助程序类是标准的，包含“测试基础结构代码”。除了测试代码，它们不属于任何其他地方。您可以选择是否测试它们。但没有它们，你的测试在大系统中是不可行的。

因此，您的选择是＃2或根本没有测试测试。重构基础设施代码以使其更加透明和简单是没有错的。

Answer 3

如果您将软件开发视为汽车生产工厂，那么编写软件的行为就像开发新车一样。每个组件都是单独测试的，因为它是新的。以前从未做过。 （如果有的话，你可以让那些之前已经完成过的人或者从货架上购买它。）

您的构建系统可以构建您的软件并对其进行测试，就像传送带一样 - 在汽车之后将汽车搅拌出来的过程。汽车制造商通常会考虑他们如何自动生产新组件并测试他们的汽车作为创建新组件的一部分，你可以打赌他们也会测试生产这些汽车的机器。

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

Answer 4

你的选择2就是我这样做的方式：首先编写助手类 - 听起来你知道应该做什么。

测试是测试，虽然辅助类不是严格测试，但它们不会被主代码引用，只会引用测试，因此它们属于测试。也许它们可能位于与常规测试不同的包/命名空间中。