当您对应用程序进行端到端测试时，您希望测试整个应用程序，而不是单元测试或集成测试等应用程序的某些部分。
但在某些情况下，人们会模拟 API。
例如，当你有一个庞大的微服务作为后端时，这使得你的 e2e 测试非常慢，或者除了你自己的 API 之外，你还依赖其他第三方 API，这使得你的 e2e 测试偶尔会失败。
那么你只想确保你的前端应用程序运行良好，你应该做什么？
在我的公司，我们有一个庞大的系统和一个非常重的数据库，这使得端到端测试非常低效。在这种场景下模拟 API 是否正确？
我的理解是，如果您只想测试前端应用程序（我认为这不是端到端测试），您可以使用单元测试。 如果您仍然想从浏览器测试用户界面，那么您可以模拟 API 的响应，但仍然不是 E2E 测试。 如果您想要执行端到端测试，那么您不应该模拟任何数据库或 API 调用。 这里的例外是不受您控制的第三方 API。 在这种特定情况下，您可以模拟它以在测试中减少外部依赖性，但如果第三方发生变化而您没有意识到它，您将不会注意到它是否被模拟。 也就是说，如果您模拟第三方 API，请确保您与 API 提供商有流畅的通信，以便在您的应用程序失败之前获得有关更改的警报。
首先，测试类型的定义和实现会有所不同，具体取决于您在行业中询问的人，但是单元测试应该只测试单个模块 - 这几乎是我见过的不同开发人员和语言之间测试的唯一协议.
正如您所说，端到端（E2E）测试通常使用“实时”但“虚拟”数据，通常来自 SIT 或 UAT 等测试环境。您的团队选择自动化这些测试 - 他们可能有充分的理由。根据我的经验，至少对于中型和小型项目，这些类型的测试更常见的是手动执行，并且更常见的是由 QA 执行。然而，这与你的问题有点相切。
我相信您真正想要的是系统测试。
Unit Tests -> Integration Tests -> Systems Tests
系统测试是通常使用模拟客户端请求来测试应用程序端点（HTTP 控制器、CLI 命令）响应的测试，使用模拟依赖项（速度、简单性）或测试工具依赖项，如内存数据库（准确性）。
因此，您可以享受执行请求的好处，该请求会遍历整个（或大部分）应用程序，而不是实际使用缓慢的实时数据，并返回一个响应，您可以对其进行测试。
但是请理解，这是一种权衡。
您可以加快测试应用程序框架是否按预期返回响应的速度，但同时它也有些脆弱，因为模拟本质上并不总是准确的。
实时依赖项可以随时更改其数据结构或修复影响响应的问题 - 在有人手动发现该更改之前，您的模拟不会考虑这些问题。
根据应用程序的不同，延迟发现模拟依赖项的测试套件全部通过绿色，实际上与现实不符，可能是不可接受的。
这个原因可能就是您的团队选择使用自动化实时 E2E 测试的原因。