Selenium 的最佳测试量 [英] Optimal amount of testing for Selenium

问题描述

这个问题是在 Selenium 的背景下出现的，但它实际上是关于一般生产质量"软件的内部测试.

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

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

<前><代码>尝试:my_element = driver.find_element_by_xpath('some_xpath')除了 NoSuchElementException:经过

或者，像这样(参见例如，selenium 测试 w/find_elements):

尝试:my_multiple_elements = driver.find_elements_by_xpath('some_xpath')如果(my_multiple_elements > 0):# 成功别的:引发异常()除了 NoSuchElementException:引发异常()

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

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

<前><代码>类 MyObject(对象):def __init__(self, x):自我.x = x定义主():x = 5my_obj = MyObject(5)# 测试如果(my_obj 是 None):引发异常()

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

最终，普遍的问题是:在编写生产质量的软件时，必须测试一些东西(参见场景 1).在这种情况下，测试应该有多彻底?或者，如果某些东西可能不会失败，我是否应该对其进行测试(参见场景 2).

编辑:对代码示例进行了一些更改，以反映更强大的测试.

解决方案

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

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

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

总而言之，至少在场景 2 中找到一个很好的平衡是非常重要的，在考虑在生产代码中进行检查时，您需要问的问题是特定的代码段是否取决于某种您做出假设的输入.

This question arises in the context of Selenium, but it's really about internal testing in "production quality" software in general.

Basically, there are two things in Selenium that I am debating whether an internal test is needed and if so, how best to implement the test. (By internal test, I mean a test that is implemented within the script or library itself; not a dedicated unittest.)

1. Navigating through webpages in Selenium should always (IMHO) have internal tests to make sure that the webdriver has reached the correct target or the page is laid out correctly. These tests usually go something like this:

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()

If we assume we're only looking for a single occurrence, which is the better internal test? It's possible that if the target site is changed, a previously unique xpath (returning only a single occurrence) may now return multiple occurrences making find_elements the more robust test. But what about time & space efficiency in running find_elements? (Assuming that find_elements must parse the whole document and therefore take longer.) Time efficiency may not be that bad for one Selenium test but what about 1,000?

2. Checking whether the webdriver has actually closed (see, e.g., checking for webdriver quit) or whether a [webdriver] object is actually created. Both these events have very low failure rates. In fact, neither of these actions have EVER failed, at least as far as I know. Additionally, I rarely--if ever--see projects where people test object instantiation. I.e.,

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()

My question for this is: why? Isn't it possible, however remote, that a constructor will fail to produce an object when called? Is the counter argument just that there is a slippery slope from checking object instantiation to checking variable instantiation to checking everything? Or is it true that due to space/time constraints, internal testing to that degree is simply unnecessary?

Ultimately, the general question is: When writing production quality software, some stuff has to be tested (see scenario 1). In that case, how thorough should the test be? OR if some stuff is likely not going to fail, should I test it at all (see scenario 2).

EDIT: Made some changes to the code example to reflect more robust testing.

解决方案

What you describe is probably best called "defensive programming": assuming that inputs to your code will break any assumptions you make about them.

So in your scenario 1, you'll never know whether a given web page at a given point in time will conform to the structure you assume, or whether it will actually be accessible in the first place. These are good reasons to perform checks.

On the other hand, checking object instantiation is out of scope of that kind of checking, provided that it doesn't depend on outside conditions. What's considered "outside" is up for debate, of course: If you consider the selenium server and browser to be part of your system and assume it's completely under control, you don't need to check successful instantiation of the webdriver object. From the point of view of only your Python process, selenium and the browser may, however, also be considered "outside", so checks may be in order. In mym opinion, the latter attitude makes sense for a library that may be used under unforeseen conditions.

To wrap it up, at least scenario 2 is very much a matter of finding a good balance, and the question you need to ask when considering a check within your production code is whether the particular piece of code depends on some kind of input you make assumptions about.

这篇关于Selenium 的最佳测试量的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！