我有Python based web scraping pet project我试图实施一些TDD,但我很快就遇到了问题。单元测试需要互联网连接,以及下载html文本。虽然我理解实际的解析可以使用本地文件完成,但是一些方法用于简单地重新定义URL并再次查询网站。这似乎打破了TDD的一些最佳实践(引用:罗伯特·马丁的清洁代码声称测试应该在任何环境中都可以运行)。虽然这是一个Python项目,但我遇到了类似的问题,使用R进行雅虎财务搜索,我确信这种事情与语言无关。至少,这个问题似乎违反了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)
答案 0 :(得分:1)
正如你所说,在TDD期间运行的测试必须运行得很快,还有其他方面,比如确定性等等(所以,如果连接断开怎么办?)。正如评论中提到的那样,这通常意味着您必须对那些令人不安的依赖项使用模拟。
然而,这里有一个潜在的假设:即,您正在编写的代码可以通过单元测试进行合理的测试。这是什么意思?这意味着单元测试找到错误的可能性很高。换句话说,如果不太可能发现单元测试的错误,单元测试就不是正确的做法。关于函数makeDataDictionary
,它主要包含对依赖项的调用。因此,似乎集成测试(即,检查代码如何与其使用的真实库交互的测试)将有助于发现错误:您的代码是否使用正确的参数正确调用库?图书馆是否按照您期望的方式提供结果?互动的顺序是否正确?模拟库中的模拟器不会回答这些问题:如果您对使用的库的假设是错误的,那么您将根据错误的假设实现模拟。
另一方面,如果你嘲笑makeDataDictionary
的所有依赖项,你期望发现什么错误?可能(在函数的最后一行),数据字典本身的创建可能是错误的(例如,键的名称错误)。因此,从我的角度来看,这一行是makeDataDictionary
中实际单元测试有意义的唯一部分。
因此,我在这种情况下的建议是首先将代码与纯逻辑(算法代码)从交互主导的代码中分离出来。例如,创建一个帮助方法_makeDataDictionary(html, text, soup)
除了返回{"html": html, "text": text, "soup": soup}
之外什么都不做。然后,将单元测试应用于_makeDataDictionary
,但不应用于makeDataDictionary
。相反,使用集成测试来测试makeDataDictionary
。
这也为模拟节省了大量精力:对于单元测试_makeDataDictionary
,不需要模拟。对于集成测试makeDataDictionary
,模拟是没有意义的。对于调用makeDataDictionary
且应进行单元测试的代码,最好将整个调用存根到makeDataDictionary
,而不是替换其各自的依赖项。
然而,在TDD环境中,这有点难以处理:TDD似乎没有代码的概念,单元测试是不合适的。但是,如果你需要适当的思考(也称为设计阶段),你可以尽早识别是否应该将算法代码与交互主导的代码分开。另一个例子是人们不应该误导TDD消除了对一些正确设计工作的需要。
答案 1 :(得分:0)
模拟 http 请求不是一项微不足道的任务,您可能需要更多 html 之外的信息,但是有一些包可以让您记录 http 请求和所有数据,我建议您查看 betamax 和 { {3}}