我的应用程序，除其他外，使用一些爬虫来读取另一个应用程序的远程 xml 提要公开的信息（我们对此不负责）。抓取的数据稍后会显示给用户。xml 可能包含简单的数据和链接，如果我们需要额外的数据，我们会遵循这些数据和链接。
我们系统中的测试既是单元测试，即我们正确解析 xml 文档的测试，也是验收测试，旨在测试我们在 ui 中显示的内容。
我在推理验收测试，这就是这个问题的意义所在。现在，对于每个验收测试，我们都会带一个嵌入式 http 服务器来提供一些测试数据，这些数据是特定于测试的。然后我们启动我们的应用程序，抓取测试数据并验证测试标准。虽然这种方法具有端到端测试整个系统的优势，但它也有副作用，即每次我们添加新的验收测试时都会显着增加构建时间。
这是验收测试的正确方法吗？我想知道，既然提供提要的系统是外部系统，那么在单元级别测试网络通信层和爬虫并假设数据已经被爬取并运行验收测试不是更好吗？
我想听听别人的一些想法。:-)
谢谢！
验收测试确实往往运行缓慢，需要更多设置并且往往比单元测试或集成测试更脆弱。如果你在网上搜索“测试金字塔”，你会发现很多关于这方面的信息。普遍的共识是您应该在单元、集成和接受级别进行测试。大多数测试都是单元测试，而只有少数验收测试可以完成端到端的工作。通常，开发团队会将他们的 ci 服务器设置为仅在他们的夜间构建过程中运行任何长时间运行的验收测试，这样它们就不会影响单元测试测试运行的性能。
我同意Andrew写的内容，但想为答案添加一个不同的角度，我认为在此类讨论中经常会忽略这一点。
您的团队正在构建产品，而您的公司希望从这项工作中获得最大的性价比。
一开始你可能会认为测试会拖慢你的速度——你的系统很简单，每个人都理解它，所以为什么要浪费时间。编写测试可能会让您感觉物有所值。但是，如果您对产品开发采取更长远的观点，这显然是错误的。但我会在这里停下来，因为我正在向皈依者传道。
但是，如果您在尝试回答问题时采用相同的心态，您会发现实际上答案在很大程度上取决于您的情况。我将使用一个相当简化的数学模型来解释我的想法：
假设P(bug | test)a 的概率bug，假设您正在运行test，让C(test)表示运行测试的成本，让C(bug)表示错误的成本。
如果您专注于特定的错误*，您希望最小化以下内容：
P(bug | test_1)*C(bug) + C(test_1) ... P(bug | test_n)*C(bug) + C(test_n)
您的套件由n测试组成。
如果您不考虑测试成本，显然您拥有的测试越多越好，对吧？但是因为测试需要维护、执行等，所以它们的成本是非零的。这意味着你有一个权衡，最后你在这里执行 U 曲线优化（有点像这张图片，他们试图在发布和持有成本之间找到最佳权衡）。
实际成本在很大程度上取决于特定领域、产品领域和测试类型。
如果您从事银行业务，则错误的成本可能会很大，因此它将使测试成本相形见绌。但是，如果您正在为音乐编写推荐引擎，那么保留几个小时的建议将不是问题。实际上，在后一种情况下，您可能希望自由地试验不同的算法和快速迭代的能力，因此测试的成本可能会掩盖错误的成本。
假设您从事特定产品的工作。即使这样也不是同质的。您的产品的某些领域将比其他领域更重要。以推特为例，如果一个人不能发推文或加载他们关注的推文，那将是一个大问题。另一方面，如果“建议听从谁”为空，对产品的影响会小很多。
最后，测试的成本也不统一。但正如我之前所说，它不可忽略，需要谨慎考虑。我在测试覆盖率低的地方工作，因为他们缺乏将更改推向生产的信心，以及在测试运行时间过长以至于人们抱怨他们一直在构建并且几乎没有工作的地方。
最后一件事。在构建时考虑到对失败的弹性是很好的——这将为您降低错误的成本。
