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