如果我有微服务，该微服务应创建用户，但是由于用户创建很复杂，因此它使用队列，而用户实际上是由使用者创建的，端点仅接受请求并返回确定或失败。
如何为此验收标准创建验收测试：
给出：要注册的用户
何时：需要api来创建用户
然后：创建用户并为新用户设置托管environment_id
为此，我必须等待实际设置环境的过程，这最多需要30秒。而且，如果我在测试中实现了睡眠，那么我会尝试使用反模式wait and see来正确测试它，而不会失败，最好的做法是什么？
答案 0 :(得分：1)
最合适的方法是，立即返回响应，假设“安装过程已启动”（具有安装过程ID），然后又有了另一个API方法，该方法将“获取安装状态”（针对该安装过程ID）-然后在“设置完成”时继续。
因为这样，无论在测试还是在生产中，都不会卡住30秒钟-并且可以向用户显示进度条，指示当前状态，以便他们可以估算需要多长时间-虽然没有得到印象，但有些东西卡住了或无法使用。
几乎没有人可以异步测试，而设置过程本身不会是异步的；没有任何状态指示器的长期运行任务几乎无法交付-因为这只有在知道后台发生了什么时才是有效的，而不是在不知道的情况下才有效。
每当测试遇到反模式时，这就是一个指标，表明解决方案可能可能不是最优的。
答案 1 :(得分：1)
我不希望告诉您确切的编码方式，而无需提供有关语言或测试堆栈的更多详细信息，但是最简单的解决方案是实施动态等待，以便在轮询系统状态之前连续轮询所需的结果继续前进，在收到预期/期望的响应时，中断循环（假定您将使用某种形式的循环，但这取决于您）。
此“轮询”可以采用多种形式，例如：
a）查询数据库的预期更新（也许在创建用户时表中的值会更新）
b）对从属服务执行ping操作，直到收到正确的“信号”（您希望指示用户创建）为止。例如，也许对另一个服务（或同一服务的另一个端点）的GET请求为给定的用户返回“创建”状态，表示该用户已被创建。
没有更多的技术信息，我无法给您确切的说明，但是动态轮询是我每天用来测试异步微服务架构的解决方案。
请记住，此动态轮询解决方案的前提是您有权访问需要进行轮询的指标的服务和/或数据库。与您的测试。再说一次，我前进的信号是透明的，例如新创建用户的状态更改，用户在微服务外部或内部的数据库/表中的存在等。
在这种情况下的其他一些假设是：
a）被测系统具有足够的非功能性能，而被测系统较差的非功能性能将成为制约因素。
b）缺乏资源约束，因为在“轮询”期间资源被大量消耗，因为在“轮询”期间资源被大量消耗。 （请考虑使用Azure动态资源伸缩，随着时间的流逝，这可能会花费很多成本。）注意：小心无限循环。在一段合理的时间或尝试次数后，您应该插入某种约束以退出轮询循环（并可能导致测试失败）。
答案 2 :(得分：0)
创建一个提供给用户属性（id或name等）的查询服务，该服务将返回用户的状态。
对于接受标准，将分为2部分
create-user服务返回200 get-status服务返回200（您可以在测试中循环调用它）。由于各种原因，这项服务从长远来看将是有帮助的