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