java - 如何从 TDD 开始 RESTful api

Question

我正在尝试练习 TDD，并且有一个练习要做。互联网某处部署了一项现有服务，具有公共(public) RESTful api。对此 api 的每个请求都需要一些数据准备，例如有效的请求字符串构造、一些加密、一些正文消息格式等。我想使用 TDD 为这项服务编写通用客户端。

我知道这并不像例如StringCalculator kata，并且需要一些不同的方法。

我不知道如何开始。我想在不使用真实服务的情况下对其进行测试，因此需要某种虚假的暗示。编写一些伪造的实现，将其部署在本地主机上并从我的测试中调用它是否更好？或者模拟一个负责发送 http 请求的类？

我希望我的客户端用法如下:

public class ServiceClientTest {
   @Test
   public void testSendStoreRequest() {
        ServiceClient client = new ServiceClient("app_key", "private_key")
        ClientResponse response = client.sendStoreRequest(StorageType.NORMAL,     "string_to_store");
       assertEquals("200", response.getStatus());
   } 
}

你能给我指明如何开始的方向吗？我应该自下而上并编写所有组件(用于请求字符串创建、加密等)然后在 ServiceClient 中使用它们，还是应该从 ServiceClient 测试和实现开始自上而下和模拟？

Answer 1

First of all , don't mock external APIs .为什么？ Cos you don't own them .

您的问题的理想解决方案似乎就是您开始描述的内容。您应该在您的项目中创建一个您拥有的接口(interface)，它将代表外部服务。

public interface CalculatorService {
    int add(int a, int b);
}

这将是您用于测试的边界。您所有的 UNIT 和 ACCEPTANCE 测试都应该针对 CalculatorService 的模拟或 stub 运行。他们会很快。您可以这样做，因为是您定义了该契约(Contract)(该接口(interface)的实际含义)。

稍后，您将有一个用于该远程 HTTP rest 服务的实现:

class RemoteRestCalculator implements CalculatorService {
    public int add(int a, int b) {
        // call the remote service in here
    }
}

你需要测试这个契约(Contract)(边框)。因此，您将为 RemoteRestCalculator 编写集成测试。您还可以进行一些端到端测试，使用 RemoteRestCalculator 运行应用程序以测试接线等。

现在，回答你的问题，如何测试 RemoteRestCalculator？

1. 理想情况下，您会在测试环境中部署一个真正的 http rest 服务实例，将其指向测试数据库等。因此，您与拥有该服务的人员交谈，他们会为您提供使用 *.war 文件，然后使用测试数据库等将其部署到本地。有时他们会为您完成该服务的“沙盒”部署。。 然后您为针对该实例运行的 RemoteRestCalculator 编写测试。
2. 另一个解决方案与您提到的类似。创建一个“http rest 服务模拟器”。然后部署到本地。 诀窍在于您必须为您在该模拟器中使用的所有功能复制真实的服务行为。因此，模拟器的“添加”方法必须与真实方法的行为相同。这个解决方案有很多优点和缺点。 然后您为针对该模拟器运行的 RemoteRestCalculator 编写测试。
3. 有一种中间解决方案在行业中被广泛使用。您只需针对真实服务(或有时是模拟器)的本地测试部署运行所有测试。 不幸的是，在这种情况下，当您有很多测试时，测试套件可能会非常慢。不推荐。 Further reading about making builds go faster .
4. 还有一种常用的解决方案，在大多数情况下不推荐使用。您创建了一个“http rest stub 类”，它的使用有点像 mockito mock，但它总是通过 http 进行通信。所以通常它会启动一个 http 服务器，你会在使用它之前准备好它。它的缺点比优点多得多。最大的缺点是服务的行为(外部依赖)分散在应用程序的许多测试中。 不推荐。