我目前正在做一些验收测试，这将有助于推动我即将进行的程序的设计。一切似乎都很好，只是我意识到验收测试有点复杂，也就是说，尽管它们在概念上很简单，但它们需要相当多的棘手代码才能运行。我需要为我的验收测试创建几个“帮助”类。
我的问题是如何开发它们：
一位朋友非常热衷于验收测试告诉您代码是否损坏，而单元测试告诉您代码损坏的地方。这些是互补且有价值的信息。验收测试更擅长让您知道何时完成。
但是要完成，您需要一路上的所有部分；您需要它们正常工作，而这正是单元测试所擅长的。先完成测试，它们还将引导您进行更好的设计（不仅仅是有效的代码）。一个好的方法是编写一个全局验收测试，然后对自己说：“当它通过时，我就完成了。” 然后努力使其通过，工作 TDD：为使 AT 通过所需的下一点功能编写一个小单元测试；编写代码使其通过；重构；重复。随着你的进步，不时运行AT；您可能会在测试的后期和后期发现它失败。而且，如上所述，当它通过时，你就完成了。
我认为对验收测试本身进行单元测试没有多大意义。但是对它的助手类进行单元测试——事实上，首先编写它们——是一个很好的方法。您可能会发现一些您编写的“仅用于测试”的方法正在进入生产代码 - 即使您不这样做，您仍然想知道您的 AT 使用的代码是否正常工作。
如果您的 AT 足够简单，那么“测试测试代码，代码测试测试”这句古老的格言可能就足够了 - 当您的测试失败时，要么是因为代码错误，要么是因为测试错误，并且应该很容易找出哪个。但是当测试很复杂时，最好也对其基础进行很好的测试。
使用单元测试框架（如 JUnit）编写验收测试（或集成测试）并没有错。人们不喜欢称它们为“单元测试”，原因有很多。对我来说，主要原因是集成/验收测试不会在每次检查更改时运行（太长或/和没有适当的环境）。
您的帮助程序类是包含“测试基础结构代码”的相当标准的东西。它们不属于其他任何地方，只属于测试代码。是否测试它们是您的选择。但是没有它们，您的测试将无法在大型系统中进行。
因此，您的选择是 #2 或根本不进行测试。重构基础设施代码以使其更加透明和简单并没有错。
如果您将软件开发视为汽车生产厂，那么编写软件的行为就像开发一辆新车。每个组件都单独测试，因为它是新的。这是以前从未做过的。（如果有，你可以找以前做过的人，也可以直接买。）
你的构建系统，它构建你的软件并对其进行测试，就像传送带——一个接一个接一个接一个地生产的过程。汽车制造商通常会考虑他们将如何自动化生产新部件并测试他们的汽车作为创造新部件的一部分，你可以打赌他们也会测试生产这些汽车的机器。
所以，是的，对你的验收测试进行单元测试对我来说似乎非常好，特别是如果它可以帮助你更快地进行并且让事情更容易改变。
您的选项 2 是我的做法：先编写帮助程序类测试 - 听起来您知道他们应该做什么。
测试就是测试，虽然帮助类不是严格的测试，但它们不会被你的主代码引用，只是测试，所以它们属于测试。也许它们可以在与常规测试不同的包/命名空间中。