#1 楼
是否仍然需要编写旨在验证那些业务规则实施的验收测试？
是的，这是绝对必要的。
您的单元测试将单独涵盖业务规则。您的验收测试可以从客户角度验证应用程序正确实施了那些业务规则。
在很多情况下，业务规则的单元测试通过，但是集成问题导致这些规则的验收测试失败。
单元测试-仅隔离测试单元。它们不以客户为中心。
集成测试-测试单元是否可以协同工作。它们不以客户为中心。
验收测试-测试客户的用例是否完整，可以满足客户的需求。它们以客户为中心，并且可以由客户而不是开发团队执行。
评论
他们不是。集成测试不是从客户角度出发。
–凯特·保罗克♦
17年1月10日在13:14
您需要单元测试，集成测试和验收测试。
–凯特·保罗克♦
17年1月10日在13:19
@MohammadaminKhayat这不是在谈论在不同级别使用相同的测试。它涉及对每个级别使用适当的测试。
–凯特·保罗克♦
17年1月10日在14:57
@MohammadaminKhayat：考虑业务规则的单元测试通过的可能性（因为规则正确），但是由于某些配置错误或其他可怕的错误，业务规则的接受测试失败了，代码并不总是在需要时调用业务规则。坦白说，如果您只打算测试一次以避免重复（我不建议这样做，但这似乎是您的动力），请继续进行验收测试。单元测试非常有用，并且使工作更轻松，而验收测试则确定您是否创建了用户想要的东西。
–史蒂夫·杰索普（Steve Jessop）
17年1月10日在16:35
...以另一种方式来看，单元测试说：“我们有一个函数/类/实现了应用程序所要求的特定行为的任何东西”，而验收测试则尽可能地表示：所需的行为”。这是您拥有一把螺丝起子的测试与家具被拧在一起的测试之间的区别；-)也就是说，如果您的验收测试足以证明已经调用了正确的业务规则，那可能就足够了而不必重新测试规则中所有可能的边缘情况。
–史蒂夫·杰索普（Steve Jessop）
17年1月10日在16:45
#2 楼
是的，您应该具有验证经过单元测试的业务规则的方案。出于某些原因：
好的单元测试模拟并存根数据存储。验收测试可确保其配置正确并且可以正常工作。
单元测试通常测试逻辑，但不允许可用性和可访问性
单元测试不能测试应用程序是否可以在多种设备上正常工作，
困扰系统的许多问题都归因于软件配置管理，并且需要经常在“登台”服务器上使用反映生产配置的可验收的系统。开发人员设置通常不反映生产配置。
评论
我知道验收测试的价值，但是在这种情况下，我是否需要进行验收测试来验证已经由单元测试验证过的业务规则？
–多态
17年1月10日在12:03
好的，所以您不知道这些规则是否真正在应用程序本身的上下文中起作用。如果需要登录并且您无法登录，则规则无关紧要。但是在隔离单元测试中测试规则是可以的。是的，我们明白了。我认为您此时正在重复自己的答案（“否”）:)
–迈克尔·杜兰特（Michael Durrant）
17年1月10日在12:44
#3 楼
好的单元测试不能与验收测试互换。它们是不同的概念，服务于不同的目的。单元测试，顾名思义，它们旨在测试单个单元。此外，您如何定义“好的”单元测试？
就像您是客户一样进行验收测试，您希望代码的所有各个单元都已经集成在一起；如果您不执行验收测试，您将如何检测单元之间的通信问题？
评论
我指的是系统的特定部分：“业务规则”，这意味着我拥有实施业务规则的单元。我能够使用适当的测试用例和测试数据对这些单元进行单元测试，并确保在我更改其范围内的某些内容时它们能够通过测试。我并没有告诉我根本不会编写验收测试，但是我的问题是：“是否有必要提供一些场景来验证那些经过单元测试的业务规则？”
–多态
17年1月10日在8:25
#4 楼
是的，大多数时候您都这样做。我个人已经实现了一些新功能TDD，在我的类中实现了100％的单元测试覆盖率，但是我忘了更新在自举。我需要添加一些集成测试来解决这种情况。
最终，您还希望通过几个测试来检查完整的end-2-end堆栈。如果不仅要确保某些问题，您可以在以后的阶段中添加这些类型的测试。例如，当某些东西很难在单元级别进行测试时。如果您从一开始就没有创建End-2-end测试，那么您可能会意识到直到建立UI都是无法测试的或很难测试的。测试类型，了解有关测试金字塔的信息。仍然主要专注于单元测试是好的，但还不够好。
其他内容：
https://testing.googleblog.com/2015 /04/just-say-say-no-to-to-more-end-to-end-tests.html
评论
有用的链接。我还关注了这两个链接：robbagby.com/posts/acceptance-tests-dont-replace-unit-tests和symphonious.net/2015/04/30/making-end-to-end-tests-work
–多态
17年1月10日在12:58
#5 楼
正如其他人所提到的，单元测试隔离地涵盖了功能。有一个很好的例子说明了为什么最近发生的事情还不够。可以在这里看到：https://www.youtube.com/watch?v=0GypdsJulKE现在，这很有趣，而且开了一个很好的玩笑，但记住代码没有不是生活在真空中。软件由必须协同工作的组件组成。单元测试是关于隔离单个组件并确保其行为符合应有的方式。集成和验收测试旨在确保组件协同工作以符合验收标准，并进而满足业务需求。
评论
实际上，我认为该youtube视频中描绘的测试是单元测试和集成测试；以同样的方式进行验收测试将是第二个人尝试进入房间-因此，即使锁适合门（成功的集成测试），第二个人也可能会通过窗户进入并导致验收失败测试。
–丹·亨德森（Dan Henderson）
17年1月12日14:22
#6 楼
单元测试和集成测试旨在促进产品开发。无论首先在何处发现问题，在这一领域中过于简化都会导致回归测试和故障/故障隔离的困难。验收测试通常以最终用户或客户同意的方式进行，并且仅专注于他们期望看到的功能和性能结果。本质上不希望将验收测试用于故障隔离，即使在验收测试中发现了故障也是如此。它们可能用于收集对可能导致故障的原因的了解，但不应过于复杂，以至于它们也应被用来确定软件的根本原因。
请注意，验收测试失败可能不是由于软件故障引起的。这可能是由于在理解需求和错误实施方面的错误。单元测试和集成测试不一定会发现这种类型的故障。
#7 楼
好的单元测试是您的第一道防线。但是，正如任何战略家都会告诉您的那样，只有一道防线是远远不够的。您期望某些单元测试将无法捕获某些问题（或者很难为其编写单元测试，或者测试编码人员没有考虑某种组合，或者错误以意外方式发生-原因很多）进行更高级别的测试。它称为“纵深防御”策略。阅读策略。 Sun-Tzu是一个超过2千年的好开始：-)
#8 楼
单元测试和验收测试需要根本不同的方法单元测试会检查您的代码是否确实符合您的想法，而不是这样做是否正确。一个好的单元测试可以检查您是否已实现函数（或单元）的低级结构，而没有任何直接错误。
验收测试可以检查您的小代码单元的组合在总体上是明智的并针对您的用例进行更正。您已经验证了代码可以满足单元测试的预期，但是验收测试可以帮助您检查思维模型是否正确，并且所编写的代码确实可以解决您要解决的问题。
评论
这个问题有什么不清楚的地方？人们为什么投票关闭它？@dzieciou我怀疑我们有新成员的“关闭黑手党”，这些成员最近获得了足够的经验值，因此他们可以关闭问题，所以他们这样做。你知道他们是谁吗？提示：他们都没有回答问题。
问问自己，如果系统测试人员或最终用户发现错误，即您的测试不是他们执行的测试，您是否也应该执行了？