python - Selenium 的最佳测试量

Question

这个问题是在 Selenium 的背景下出现的，但实际上它实际上与“生产质量”软件的内部测试有关。

基本上，Selenium 中有两件事我正在争论是否需要内部测试，如果需要，如何最好地实现测试。 (内部测试是指在脚本或库本身内实现的测试；而不是专用的单元测试。)

1. 在 Selenium 中浏览网页应该始终(恕我直言)进行内部测试，以确保网络驱动程序已达到正确的目标或页面布局正确。这些测试通常是这样的:

try:
  my_element = driver.find_element_by_xpath('some_xpath')
except NoSuchElementException:
  pass

OR alternatively, like this (see e.g., selenium testing w/find_elements):

try:
  my_multiple_elements = driver.find_elements_by_xpath('some_xpath')
  if (my_multiple_elements > 0):
    # success
  else:
    raise Exception()
except NoSuchElementException:
  raise Exception()

如果我们假设我们只寻找单个事件，那么哪个内部测试更好？如果目标站点发生更改，以前唯一的 xpath(仅返回单个匹配项)现在可能会返回多个匹配项，从而使 find_elements 成为更稳健的测试。但是运行 find_elements 的时间和空间效率如何呢？ (假设 find_elements 必须解析整个文档，因此需要更长的时间。)时间效率对于一个 Selenium 测试来说可能还不错，但是对于 1,000 个测试呢？

检查 webdriver 是否已实际关闭(例如，参见 checking for webdriver quit )或 [webdriver] 对象是否已实际创建。这两个事件的失败率都非常低。事实上，至少据我所知，这些行动都没有失败过。此外，我很少(如果有的话)看到人们测试对象实例化的项目。即，

class MyObject(object):
  def __init__(self, x):
    self.x = x

def main():
  x = 5
  my_obj = MyObject(5)

  # TESTING
  if (my_obj is None):
    raise Exception()

我的问题是:为什么？无论多么遥远，构造函数在调用时都可能无法生成对象，这不是可能吗？反驳的论点是否只是说从检查对象实例化到检查变量实例化再到检查所有内容存在一个滑坡？或者说，由于空间/时间的限制，这种程度的内部测试根本没有必要？

最终，普遍的问题是:在编写生产质量软件时，必须测试某些内容(参见场景 1)。那么，测试应该有多彻底呢？或者，如果某些东西可能不会失败，我是否应该测试它(参见场景 2)。

编辑:对代码示例进行了一些更改，以反射(reflect)更强大测试。

Answer 1

您所描述的内容可能最好称为“防御性编程”:假设代码的输入将打破您对它们所做的任何假设。

因此，在场景 1 中，您永远不会知道给定网页在给定时间点是否符合您假设的结构，或者它是否实际上可以首先访问。这些是执行检查的充分理由。

另一方面，检查对象实例化超出了此类检查的范围，前提是它不依赖于外部条件。当然，什么被认为是“外部”是有争议的:如果您认为 selenium 服务器和浏览器是系统的一部分，并假设它完全受到控制，则不需要检查 webdriver 对象的成功实例化。然而，仅从 Python 进程的角度来看，selenium 和浏览器也可能被视为“外部”，因此检查可能是有序的。在我看来，后一种态度对于可能在不可预见的条件下使用的库来说是有意义的。

总而言之，至少场景 2 是一个找到良好平衡的问题，在考虑对生产代码进行检查时您需要问的问题是特定的代码片段是否依赖于某种类型您做出假设的输入。