我有一个 API，我想以自动化方式进行测试。我目前正在用 java 做，但我认为问题与语言无关
一点上下文：
主要思想是以类似于this demo的方式与支付系统集成。
主要流程是这样的：
我的主要问题是如何针对这种场景进行自动化集成测试？我的主要想法：
【问题讨论】：
标签： java web-services unit-testing tdd automated-tests
我认为答案取决于您的集成测试的目标和范围，以及用于集成测试的合适平台的可用性。这里有一些想法可能会帮助您做出决定，首先关注的是确定您的测试目标，然后再对合适的测试工具提出任何建议。
（我假设您在运行测试时不想实际使用支付服务的生产版本）
测试与“真实”支付服务的集成：最强大的集成测试形式是您实际调用真实支付服务作为测试的一部分，因为这将测试代码您的应用程序、支付服务中的代码以及两者之间的通信。但是，这要求您有一个始终运行的可用支付服务测试版本，而且可用性越低，您的测试就越脆弱。
如果支付服务归您的团队/部门/公司所有，这可能不是那么糟糕，因为您有必要的控制来确保它始终可用于测试。但是，如果它是一个供应商系统，假设他们控制服务的测试版本，那么如果他们没有有效地维护该测试服务以提供高水平的可用性（在我的经验，他们通常不会，经常会出现问题，例如服务升级不够频繁，或者他们的支持团队没有注意到服务是否已关闭）。
您可能会遇到的一种情况是，供应商可能会提供始终运行其软件的预发布版本的测试服务，以便他们的客户可以在新版本的软件发布到生产环境之前对其进行测试并标记任何集成问题。如果他们这样做，这肯定会影响您的决定。
测试与“假”支付服务的集成：另一种方法是构建服务的假版本，在与真实服务类似的环境中运行并使用相同的 API，可以用于集成测试。这可以像您喜欢的那样简单或复杂，从一个非常瘦的服务，它只为每个请求返回一个单一的预设响应，到可以返回一系列不同响应（成功、失败、未找到服务等）的服务。 .)，具体取决于您的测试目标。
这样做的好处是不那么脆弱 - 它可能具有更高的可用性，因为它在您的控制之下，并且从您的测试中保证您正在寻找的服务的响应也将更加简单。此外，它使构建更智能的测试用例变得更加简单（即，如果服务不可用，或者如果它报告它处于高负载并且无法处理您的事务，则测试您的代码如何响应）。缺点是设置起来可能需要更多工作，而且在运行单元测试时，您并没有在实际支付服务中执行代码。
测试服务的最佳方法是什么？：这是高度特定于上下文的，但是我认为这是一种理想的测试方法，基于在有效测试之间取得平衡与服务集成，并通过脆弱的测试将影响开发人员生产力的风险降至最低。
如果供应商提供了他们服务的测试版本，请编写一个小型测试套件来验证您从他们的服务中获得了预期的响应，并每天运行一次。这将允许验证您自己对其服务行为的假设的好处，而不会给您的其余测试带来脆弱性。适当的工具将是这项工作最简单的工具（即使是通过电子邮件向您发送任何问题的 shell 脚本也绝对没问题），只要它是可维护的，归根结底，这些不会是开发人员的测试预计会定期运行。
对于我的端到端测试套件（即部署系统的测试版本并对其进行端到端测试的套件），我将构建一个伪造的支付服务版本，可以使用测试系统，并将其用于测试。这允许您完全端到端地测试您自己的系统，并使用稳定的支付服务端点。这些端到端测试应该包括无法找到服务、报告失败等情况。鉴于这是端到端测试，Selenium 等工具适用于通过 Web UI 驱动的测试。
对于其余的自动化测试，我将模拟对支付服务的调用。一种非常简单的方法是将您对支付服务的所有调用封装在系统中的单个组件中，在测试期间可以轻松地将其替换为模拟版本（例如使用依赖注入）。
【讨论】：