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