如果我有微服务，它应该创建用户，但由于用户创建很复杂，它使用队列，并且用户实际上是由消费者创建的，端点只接受请求并返回正常或失败。
如何为此验收标准创建验收测试：
给定：想要注册的用户
何时：请求创建用户的 api然后： 创建用户并在新用户上设置托管 environment_id
为此，我必须等待实际设置环境，这最多需要 30 秒。如果我在测试中实现睡眠，那么我会遇到反模式wait and see 如何正确测试它而不失败最佳实践？
【问题讨论】：
标签： java php automated-tests microservices acceptance-testing
创建一个给定用户属性（id 或 name 等）的查询服务，将返回用户的状态。
对于验收标准，将是 2 部分
create-user服务返回200get-status 服务返回 200（您可以在测试中循环调用它）。由于各种原因，这项服务从长远来看会有所帮助
【讨论】：
如果没有关于语言或测试堆栈的更多详细信息，我不会准确告诉您如何编写验收测试，但最简单的解决方案是实现动态等待，在之前不断轮询系统状态以获得所需结果当收到预期/期望的响应时，继续前进，打破循环（假设您会使用某种形式的循环，但这取决于您）。
这种“投票”可以采取多种形式，例如：
a) 查询对数据库的预期更新（可能在创建用户时更新表中的值）
b) ping 依赖服务，直到您收到您期望指示用户创建的正确“信号”。例如，对另一个服务（或同一服务的另一个端点）的 GET 请求可能会为给定用户返回“已创建”状态，表示该用户已创建。
如果没有进一步的技术信息，我无法给你确切的说明，但动态轮询是我每天用来测试我们的异步微服务架构的解决方案。
请记住，此动态轮询解决方案的运行假设您有权访问包含您正在“轮询”的指标的服务和/或数据库，当您需要继续前进时用你的测试。同样，我是向前迈进的信号是透明的，例如新创建的用户的状态更改、用户在微服务外部或内部的数据库/表中的存在等。
此场景中的其他一些假设是：
a) 被测系统有足够的非功能性性能，其中被测系统的非功能性性能不佳将是一个限制因素。
b) 缺乏资源限制，因为在“轮询”期间资源消耗有些大，因为在“轮询”期间资源消耗有些大。 （想想 Azure 动态资源弹性，随着时间的推移可能代价高昂）。
注意：小心无限循环。您应该插入某种约束，以在合理的时间段或您自行决定的尝试次数后退出轮询循环（并可能导致测试失败）。
【讨论】：
最合适的可能是，为了立即返回响应，假设“设置过程已启动”（带有设置过程 ID），然后有另一个 API 方法，它将“获取设置状态”（对于该设置过程 ID） -然后在“设置完成”时继续。
因为像这样，在测试和生产中都不会卡住 30 秒 - 并且可以向用户显示进度条，指示当前状态，以便他们估计需要多长时间 -虽然没有得到印象，但有些东西被卡住或无法正常工作。
几乎不能异步测试，而设置过程本身不会是异步的；并且没有任何状态指示器的长时间运行的任务几乎无法交付 - 因为这仅在知道后台发生的事情时才显得有效，而不是在不知道的情况下。
当测试遇到反模式时，这表明解决方案可能不是最佳的。
【讨论】：