微服务集成测试

Question

我有一个微服务，它通过一些额外的逻辑在数据库之上提供基本的CRUD操作。我想编写一个集成测试，以通过部署微服务并发出REST调用并分析返回值来测试API是否应正常工作。关于如何使用2个特定选项进行数据库清理有一些公开讨论：

1. 在常见的超类中使用通用的@ BeforeClass / @ BeforeMethod方法，该方法会将数据库中的所有数据删除到“设置”测试的干净环境中（使集成测试“框架”取决于环境）
2. 通过对@ AfterClass / @ AfterMethod中由测试保存的数据发出删除REST请求，使每个测试本身变得干净（在每个测试中添加额外的代码）

2个选项中的任何一个更可取吗？还是第三？

Answer 1

就测试集成测试的E2E功能和实用性而言，这个问题不应成为开发/部署的障碍。在我看来，选项1是更好的做法，因为您想隔离TEST来测试您希望首先测试的特定API调用。发出其他REST请求会更改测试本身的角色。

如果API方法A发出POST请求（与DB对话），并且您遵循选项2，则集成测试将测试POST和DELETE流。作为开发人员，您会知道POST请求有效，但是从外部（无论外部是什么意思）看来，这似乎意味着您正在测试无关的流程。因此，这是不好的做法。另一方面，采用与框架相关的方式来清除数据库（您的选项1）可确保您区分API调用将执行的功能以及为将来的测试进行设置所需的功能。

示例：如果您正在使用Amazon DynamoDB并编写集成测试，请执行API调用，但使用DynamoDB API清除DynamoDB（如果需要其他测试）实例。

就您所说的“使集成测试“框架”取决于环境”而言，这对我而言似乎并不明确。根据我认为您的发言，我认为这不是问题。如果DynamoDB在上述示例中失败，则您的服务（以及您的集成测试）也将始终失败，因为您的API代码始终具有上游外部依赖关系。也许，您建议使用其他软件包/客户端来处理DynamoDB清理，在这种情况下，我建议您这样做，因为这可能导致附加的依赖关系和服务的更多故障点（但也可能导致对DynamoDB的依赖性更大，因此是特定于用例的决定）。

不确定这是否有帮助，但是请随时提出一些意见，特别是如果您认为用例是唯一的和/或与我所说的不一致。