gpt4 book ai didi

python - Web 抓取的测试驱动开发 (TDD)

转载 作者:太空狗 更新时间:2023-10-29 21:09:28 25 4
gpt4 key购买 nike

总结

我有一个 Python based web scraping pet project我正在尝试在其中实现一些 TDD,但很快就遇到了问题。单元测试需要互联网连接,以及下载 html 文本。虽然我知道实际的解析 可以用本地文件来完成,但有些方法用于简单地重新定义 URL 并再次查询网站。这似乎打破了 TDD 的一些最佳实践(引用:Robert Martin 的 Clean Code 声称测试应该可以在任何环境中运行)。虽然这是一个 Python 项目,但我在使用 R 进行 Yahoo Finance 抓取时遇到了类似的问题,而且我确信这种事情与语言无关。至少,这个问题似乎违反了 TDD 中的一个主要准则,即测试应该快速运行。

tldr;在 TDD 中处理网络连接是否有任何最佳实践?

可重现的例子

AbstractScraper.py

from urllib.request import urlopen
from bs4 import BeautifulSoup


class AbstractScraper:

def __init__(self, url):
self.url = url
self.dataDictionary = None

def makeDataDictionary(self):
html = urlopen(self.url)
text = html.read().decode("utf-8")
soup = BeautifulSoup(text, "lxml")
self.dataDictionary = {"html": html, "text": text, "soup": soup}

def writeSoup(self, path):
with open(path, "w") as outfile:
outfile.write(self.dataDictionary["soup"].prettify())

TestAbstractScraper.py

import unittest
from http.client import HTTPResponse
from bs4 import BeautifulSoup
from CrackedScrapeProject.scrape.AbstractScraper import AbstractScraper
from io import StringIO


class TestAbstractScraperMethods(unittest.TestCase):

def setUp(self):
self.scraper = AbstractScraper("https://docs.python.org/2/library/unittest.html")
self.scraper.makeDataDictionary()

def test_dataDictionaryContents(self):
self.assertTrue(isinstance(self.scraper.dataDictionary, dict))
self.assertTrue(isinstance(self.scraper.dataDictionary["html"], HTTPResponse))
self.assertTrue(isinstance(self.scraper.dataDictionary["text"], str))
self.assertTrue(isinstance(self.scraper.dataDictionary["soup"], BeautifulSoup))
self.assertSetEqual(set(self.scraper.dataDictionary.keys()), set(["text", "soup", "html"]))

def test_writeSoup(self):
filePath = "C:/users/athompson/desktop/testFile.html"
self.scraper.writeSoup(filePath)
self.writtenData = open(filePath, "r").read()
self.assertEqual(self.writtenData, self.scraper.dataDictionary["soup"].prettify())

if __name__ == '__main__':
suite = unittest.TestLoader().loadTestsFromTestCase(TestAbstractScraperMethods)
unittest.TextTestRunner(verbosity=2).run(suite)

最佳答案

正如您所说,在 TDD 期间运行的测试必须快速运行,并且还有其他方面,例如确定性等(那么,如果连接中断怎么办?)。正如评论中提到的那样,这通常意味着您必须对那些令人不安的依赖项使用模拟。

然而,这里有一个潜在的假设:即,您正在编写的代码可以通过单元测试进行合理的测试。这是什么意思?这意味着单元测试找到错误的可能性相当高。换句话说,如果通过单元测试发现错误的可能性极小,那么单元测试就不是正确的做法。

关于您的函数 makeDataDictionary,它主要由对依赖项的调用组成。因此,集成测试(即检查您的代码如何与其使用的真实库交互的测试)似乎可能有助于发现错误:您的代码是否使用正确的参数正确地调用了库?图书馆是否以您期望的方式实际提供结果?交互顺序是否正确?库的模拟不会回答这些问题:如果您对所使用的库的假设是错误的,您将根据错误的假设来实现您的模拟。

另一方面,如果您从 makeDataDictionary 中模拟掉所有依赖项,您希望找到哪些错误?可能(在函数的最后一行)数据字典本身的创建可能是错误的(例如,键的名称错误)。因此,从我的角度来看,这一行是 makeDataDictionary 中实际单元测试有意义的唯一部分。

因此,在这种情况下,我的建议是首先将纯逻辑(算法代码)的代码与以交互为主的代码分开。例如,创建一个辅助方法 _makeDataDictionary(html, text, soup) 它除了返回 {"html": html, "text": text, "soup": soup} 什么都不做。然后,将单元测试应用于 _makeDataDictionary,但不应用于 makeDataDictionary。相反,使用集成测试测试 makeDataDictionary

这也节省了大量模拟工作:对于单元测试 _makeDataDictionary,不需要模拟。对于集成测试 makeDataDictionary,mock 毫无意义。对于调用 makeDataDictionary 并应进行单元测试的代码,最好将对 makeDataDictionary 的调用作为一个整体 stub ,而不是替换它的各个依赖项。

然而,在 TDD 上下文中,这有点难以处理:TDD 似乎没有不适合单元测试的代码概念。但是,通过适当的提前思考(也称为设计阶段),您可以及早认识到是否应该将算法代码与交互主导的代码分开。另一个例子表明,不应误导人们相信 TDD 消除了对某些适当设计工作的需求。

关于python - Web 抓取的测试驱动开发 (TDD),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/41324624/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com