错误 – 你还在等什么？

无论你是编写测试、编写框架还是两者兼而有之，总有一天你肯定需要让代码暂停一下。你可能觉得这么简单的事情为什么值得单独写一篇文章，但希望读完之后，你会意识到代码中的任何暂停都可能带来相当大的麻烦。

当我刚开始写测试的时候，在接触其他事情之前，我会处理那些并非最优化设计的应用程序的前端测试。通常，控件需要一段时间才能变得可用，或者页面需要一段时间才能更新，所以很自然地，我想在测试中加入等待，以应对这种情况。问题是，我当时的首选解决方案是使用臭名昭著的 `Thread.Sleep`，每次传入几秒钟。当时，这看起来完全没问题，调用起来很简单，没有开销，而且我确信 `Sleep` 调用结束后，我的应用程序就可以准备好进行测试的下一行了。

问题在于，即使每个测试中只有一个 `Thread.Sleep`，累积起来也非常可观。如果你设想每个测试只等待一秒钟，并且你的测试套件中有 1000 个测试（如果你在大公司，有很多团队，这算不了多少），那么你将花费 1000 秒仅仅用于等待。17 分钟。这听起来可能不多，但说实话，测试中一次等待一秒钟算是比较短的了。

在测试中设置十秒甚至二十秒的等待是很常见的，具体取决于你在哪里使用它，例如等待模态加载屏幕消失。但问题在于，`Thread.Sleep` 不管你的加载屏幕是两秒钟就消失了，还是比你设定的十秒钟花费的时间还要长，它只会等待你设定的时间，然后你的测试就会继续。这对后者来说是个坏消息，但对前者来说则是一种巨大的浪费。如果你的测试只需要等待两秒钟，但你却白白地等待了八秒钟，什么都没做，只是为测试增加了不必要的时间。

但是，对此有一个解决方案。这完全取决于这样一个事实：在自动化方面，等待从来不仅仅是等待。有两种不同的等待方式：`隐式`等待和`显式`等待。`隐式`等待就是我们到目前为止一直在讨论的，而且它们很容易被过度使用。它们并非一无是处，也有其合理用途，有时你就是无法避免使用它们，但对于大多数情况，你应该尽量减少使用`隐式`等待。

问题在于，虽然说起来容易，要尽可能避免使用它们，但替代方案是`显式`等待，而这些稍微复杂一些，需要更多的工作。这是因为`显式`等待只会等待它需要的时间，而不是等待固定的一段时间，但这需要一些逻辑来处理。无论是通过 `while` 循环、某种递归方法，还是使用 Selenium 等工具内置的等待库，`显式`等待很少有一行就能解决的方案。但额外的努力带来的回报是巨大的，尤其是在大量的测试中。

`显式`等待可以写成可用于整个测试的辅助工具，这不仅减少了提高测试效率所需的工作量，还能通过减少代码重复和创建强大的可重用方法来实现良好的代码设计。

正如我之前所说，不要觉得你完全不能使用`隐式`等待，有时候你就是无法避免。如果你最多只需要等待一秒钟，那么使用 `Thread.Sleep` 这样的方法可能就足够了。但是，如果你反复等待同一件事情一秒钟，那么你应该考虑创建一个`显式`等待方法来处理所有需要这种情况的地方。

而这正是本文主要想说的：运用常识和经验来决定哪种等待方式是合适的。以下是一些你在做决定时应该考虑的要点。

1. 多久一次？如果你在测试的各个地方反复等待同一个元素，问问自己，是继续使用固定的等待时间，还是值得创建一个辅助方法来处理它，并可能在使用的过程中节省时间？
2. 多久？如果你等待的时间超过一秒钟，我认为使用`显式`等待是值得的。但也要考虑该操作所需时间的变动性，保存或加载动画所需的时间可能因系统负载而异，因此你不应该设置`隐式`等待，因为你根本不知道它需要多长时间。
3. 代码重复？这结合了以上两点。如果一个等待所需的时间未知，但它只在单个测试中使用了​​一次，那么编写一个复杂的辅助方法是否真的值得你花费时间，而在这种单一情况下，测试中的某些东西可能就足够了。

当你开始学习编写测试时，很容易过度思考这个问题并给自己带来不必要的压力。给初学者的建议是，以你认为合适的方式编写测试，利用我给出的建议来帮助决定何时以及使用哪种等待方式。但最重要的是，如果你做错了，你也不是被困住了。代码重构是你将永远在你代码上进行的事情，而且这并非坏事。总有改进的空间，总有一天你可能会想出一种绝妙的方法来处理不可靠的页面加载时间，当你写出处理它的辅助方法时，你就能突然改进你的测试以使用该方法。

重要的是要认识到，如果你使用了`隐式`等待，很可能存在替代解决方案，你应该在可能的情况下解决它。但不要视而不见，让你的测试成为时间的黑洞。

那么，你还在等什么？

这篇文章 错误——你还在等什么？ 最初发布于 Learn Automation。