Python爬蟲學(xué)著學(xué)著你會發(fā)現(xiàn)一個很奇怪的現(xiàn)象很多教程都在教你怎么發(fā)請求、怎么寫解析器、怎么把數(shù)據(jù)入庫卻極少有人認(rèn)真講“怎么證明你的爬蟲是對的”。解析器寫完了沒有樣本驗證清洗函數(shù)靠肉眼觀察數(shù)據(jù)入庫之后才發(fā)現(xiàn)字段對不上。這一篇我聊測試驅(qū)動爬蟲用解析器、清洗、入庫三類測試把爬蟲項目從“能跑就行”變成“敢改敢維護”。零基礎(chǔ)剛學(xué)完P(guān)ython基礎(chǔ)、想往爬蟲方向進階的同學(xué)或者已經(jīng)寫過幾個爬蟲但總覺得代碼脆弱的初學(xué)者都可以照著這篇把工程化補上。1. 爬蟲不寫測試省下的時間最后都要加倍還回去1.1 為什么爬蟲項目普遍跳過測試先聊一個很現(xiàn)實的問題為什么爬蟲項目的測試總是被跳過我見過太多初學(xué)者包括當(dāng)年的自己的邏輯是爬蟲就是個一次性腳本跑完拿數(shù)據(jù)就完事了寫測試不是浪費時間嗎但實際情況是爬蟲是最容易出現(xiàn)“悄然變壞”的項目類型。網(wǎng)絡(luò)請求失敗會拋異常你能立刻發(fā)現(xiàn)但頁面結(jié)構(gòu)變了解析代碼可能依然正常運行只不過select出來的結(jié)果全是None入庫之后全是空字符串。這種靜默失敗最危險。我總結(jié)了三個最典型的翻車場景每一個都靠人眼盯不出來頁面結(jié)構(gòu)變了。網(wǎng)站改版、某個class名調(diào)整、布局換了你的解析函數(shù)表面上還在運行但返回的字段全是空值。等你跑完整個任務(wù)、開始分析數(shù)據(jù)時才察覺甚至說不清是哪一天開始錯的。臟數(shù)據(jù)沒有兜底。價格字段有時候是“1,299.00”有時候是“價格面議”有時候干脆是個空標(biāo)簽。如果清洗邏輯沒有處理邊界入庫的數(shù)據(jù)就是垃圾場。重復(fù)入庫。爬蟲任務(wù)通常不是跑一次就結(jié)束的定時任務(wù)、斷點續(xù)爬、調(diào)試時反復(fù)運行同一個URL可能被解析很多次。如果入庫邏輯沒有去重數(shù)據(jù)庫會越跑越臟。這三個問題靠人眼盯肯定盯不過來。測試就是那個替你把關(guān)的“機器人”任何一次解析結(jié)果異常、清洗結(jié)果越界、入庫行為不對它都能第一時間報警。1.2 解析器、清洗、入庫三條檢查線各管一攤我在爬蟲項目里只寫三類測試正好對應(yīng)數(shù)據(jù)鏈路中三個最容易出錯的位置解析器測試輸入一段HTML斷言解析結(jié)果是不是期望的結(jié)構(gòu)化數(shù)據(jù)。它守護的是“網(wǎng)頁轉(zhuǎn)字典”這一步。清洗測試輸入一個原始字符串?dāng)嘌郧逑春蟮闹?、類型、格式都正確。它守護的是“字典轉(zhuǎn)干凈字典”這一步。入庫測試把干凈數(shù)據(jù)交給存儲層斷言數(shù)據(jù)庫里實際發(fā)生了什么。它守護的是“干凈字典落庫”這一步。三條線是遞進關(guān)系解析器錯了后面全錯解析器對了但清洗錯了入庫也是錯的前兩步都對但入庫邏輯有bug數(shù)據(jù)照樣出問題。三層都測才算完整覆蓋。1.3 爬蟲場景下的TDD流程要怎么變TDD的核心流程大家可能聽過紅寫一個失敗的測試到綠用最簡實現(xiàn)讓測試通過再到重構(gòu)在測試保護下改進代碼。但在爬蟲場景里這個流程要做一點調(diào)整你沒法先寫測試去測一個還沒出現(xiàn)的網(wǎng)站但你可以先把一小段頁面樣本固定下來然后讓解析代碼去適配這段樣本并用測試保證“這段樣本的解析結(jié)果永遠符合預(yù)期”。換句話說爬蟲里的測試驅(qū)動本質(zhì)上是讓“歷史頁面”成為你的回歸基線。網(wǎng)站改版不可怕可怕的是改版之后你完全不知道哪里壞了。測試存在改版影響一眼就能掃出來。2. 可被測試的工程骨架從分層設(shè)計到固定HTML樣本2.1 分層設(shè)計每層只干一件事很多零基礎(chǔ)同學(xué)寫爬蟲喜歡把所有邏輯堆在一個腳本里發(fā)請求、解析、清洗、存庫全在一起。好處是“看起來簡單”壞處是一旦想寫測試根本無從下手。要讓代碼可測試第一步就是拆分層級。我常用的項目結(jié)構(gòu)長這樣book_spider/ ├── spider/ │ ├── __init__.py │ ├── parser.py # 解析HTML - dict │ ├── cleaner.py # 清洗dict - 干凈dict │ └── storage.py # 入庫邏輯 ├── tests/ │ ├── __init__.py │ ├── fixtures/ # 存HTML樣本 │ │ └── book_detail.html │ ├── test_parser.py │ ├── test_cleaner.py │ └── test_storage.py └── requirements.txt為什么這么分原則只有一個請求、解析、清洗、存儲每一層只干一件事層與層之間通過普通數(shù)據(jù)結(jié)構(gòu)比如字典傳遞。這樣測解析器時不需要真的發(fā)網(wǎng)絡(luò)請求測清洗函數(shù)時不需要關(guān)心頁面長什么樣測入庫時更不需要連生產(chǎn)數(shù)據(jù)庫。每一層都能獨立驗證互不牽連。2.2 最小依賴清單與pytest環(huán)境依賴方面其實很簡單核心就兩個pytest負(fù)責(zé)測試beautifulsoup4負(fù)責(zé)解析HTML。requests看你的抓取需求sqlite3是標(biāo)準(zhǔn)庫不需要額外安裝。requests2.32.3 beautifulsoup44.12.3 pytest8.3.2版本號建議鎖死。Python項目最怕的就是“昨天還能跑今天升級依賴后掛了”鎖版本可以把這個風(fēng)險降到最低。安裝完依賴后在項目根目錄運行pytest tests/ -vpytest會自動發(fā)現(xiàn)tests目錄下所有test_*.py文件。如果你用的是VS Code裝好Python插件后可以直接點擊測試函數(shù)旁邊的Run按鈕也挺方便。2.3 把頁面存成fixture讓測試確定下來這里有個非常關(guān)鍵的實操細(xì)節(jié)測試解析器時千萬別在代碼里實時請求網(wǎng)站。原因有兩個第一網(wǎng)站不是你的隨時可能改版、限流、甚至關(guān)站測試會變得不穩(wěn)定第二爬蟲測試要的是“確定性輸入”線上頁面每次返回的內(nèi)容都不一樣沒法做精確斷言。正確的做法是把一個正常的頁面HTML保存下來放進tests/fixtures目錄。我通常會寫一個加載fixture的小函數(shù)from pathlib import Path FIXTURES_DIR Path(__file__).parent / fixtures def load_fixture(name: str) - str: return (FIXTURES_DIR / name).read_text(encodingutf-8)這樣測試永遠基于一份固定的HTML只要這份HTML不變測試結(jié)果完全可預(yù)測。你甚至可以把這份HTML提交到Git倉庫項目組里任何人拉下來都能跑。2.4 先跑通一個“鏈路驗證”測試在正式用例之前我會先寫一個最傻的驗證測試確保fixture能被加載、pytest環(huán)境沒問題def test_fixture_can_be_loaded(): html load_fixture(book_detail.html) assert Python編程 in html命令行執(zhí)行pytest tests/ -v看到綠色passed說明測試鏈路已經(jīng)通了。這步的價值是把“測試基礎(chǔ)設(shè)施”先搭起來后面再往上加真實用例出了問題你也能確定是測試代碼的問題還是爬蟲代碼的問題。3. 解析器測試把不穩(wěn)定的網(wǎng)頁變成確定性的斷言3.1 解析器是第一個暴露風(fēng)險的環(huán)節(jié)解析器是爬蟲項目里最脆弱的環(huán)節(jié)。網(wǎng)絡(luò)請求失敗會拋異常你立刻能發(fā)現(xiàn)但頁面結(jié)構(gòu)變了解析代碼可能依然“正常運行”只不過返回的字段全是None或空字符串。這種靜默失敗是最危險的。所以解析器測試的目標(biāo)就是給“HTML轉(zhuǎn)字典”這一步加一個強約束。只要頁面上該有的信息沒被正確解析測試立刻掛掉讓你第一時間知道改版了。3.2 正常用例斷言解析結(jié)果是結(jié)構(gòu)化字典拿一個書籍詳情頁舉例。假設(shè)要解析書名、價格、作者三個字段。第一個測試跑的是“一切正?！钡那闆rfrom spider.parser import parse_book_detail def test_parse_book_detail_normal(): html html body h1 classtitlePython編程從入門到實踐/h1 span classprice89.00/span div classauthorEric Matthes/div /body /html result parse_book_detail(html) assert result[title] Python編程從入門到實踐 assert result[price] 89.00 assert result[author] Eric Matthes這個測試沒過說明解析函數(shù)有問題過了我們繼續(xù)加邊界條件。3.3 邊界用例缺失字段與空白文本頁面并不是永遠規(guī)規(guī)矩矩的。有的書沒有作者信息有的標(biāo)題前后帶著換行和空格有的價格被套在一個很深的div結(jié)構(gòu)里。這些都應(yīng)該寫進測試def test_parse_book_detail_missing_author(): html html body h1 classtitle Python編程從入門到實踐 /h1 span classprice89.00/span /body /html result parse_book_detail(html) assert result[title] Python編程從入門到實踐 assert result[author] def test_parse_book_detail_nested_price(): html html body h1 classtitle深入理解計算機系統(tǒng)/h1 div classprice-wrapper span classprice139.00/span /div /body /html result parse_book_detail(html) assert result[price] 139.00看明白了嗎先寫失敗用例再去實現(xiàn)解析函數(shù)這正是測試驅(qū)動的“紅”階段。3.4 實現(xiàn)時的容錯寫法與選擇器穩(wěn)定性配合上面測試的解析實現(xiàn)我推薦“能找到就返回找不到就返回空字符串”的容錯風(fēng)格from bs4 import BeautifulSoup def parse_book_detail(html: str) - dict: soup BeautifulSoup(html, html.parser) title soup.select_one(h1.title) price soup.select_one(span.price) author soup.select_one(div.author) return { title: title.get_text(stripTrue) if title else , price: price.get_text(stripTrue) if price else , author: author.get_text(stripTrue) if author else , }每個字段都做了None判斷配合get_text(stripTrue)把首尾空白去掉。很多人剛學(xué)BeautifulSoup時習(xí)慣直接soup.find(h1).text一旦找不到節(jié)點就拋AttributeError整個爬蟲直接崩。容錯寫法雖然多打幾行字但健壯性完全不同。選擇器是另一個容易踩坑的地方。比如頁面class名從price變成price highlightselect_one(span.price)依然能匹配到因為class屬性包含price。但如果你寫成select_one(span[classprice])這種屬性精確選擇就會掛。所以寫選擇器時我會先去瀏覽器開發(fā)者工具里復(fù)制真實節(jié)點出來確認(rèn)class完整值再寫測試。選擇器寧可寫得寬一點也別寫得窄到只能匹配當(dāng)前一版頁面。測試的價值就在這里你改了選擇器跑一遍測試就知道有沒有影響其他用例。4. 清洗測試邊界條件才是臟數(shù)據(jù)治理的核心4.1 清洗函數(shù)必須是純函數(shù)解析完成后拿到的字段還是“原始狀態(tài)”價格是“1,299.00”這種字符串日期是“2024年12月1日”描述文本里可能還帶著HTML標(biāo)簽。清洗層的任務(wù)就是把五花八門的raw值變成規(guī)整的、可直接入庫的數(shù)據(jù)。這里有一個關(guān)鍵設(shè)計原則清洗函數(shù)必須是“純函數(shù)”。所謂純函數(shù)就是同樣的輸入永遠得到同樣的輸出不依賴外部狀態(tài)不修改傳入?yún)?shù)。好處是測試極其好寫——不用準(zhǔn)備數(shù)據(jù)庫、不用發(fā)網(wǎng)絡(luò)請求丟一個字符串進去斷言返回值即可。4.2 參數(shù)化測試一組用例覆蓋價格、日期、文本pytest有個非常好用的功能叫參數(shù)化特別適合清洗場景。拿價格清洗舉例import pytest from spider.cleaner import clean_price pytest.mark.parametrize(raw,expected, [ (1,299.00, 1299.0), (89.00, 89.0), ($1,234.56, 1234.56), (價格999, 999.0), (, None), (免費, None), (暫無報價, None), ]) def test_clean_price(raw, expected): assert clean_price(raw) expected這段代碼的價值非常大你掃一眼用例列表就知道清洗函數(shù)支持哪些格式、遇到什么情況返回None。以后需求變了比如要支持歐元直接加一行參數(shù)繼續(xù)跑誰也沒法偷偷改壞你之前調(diào)好的邏輯。對應(yīng)的實現(xiàn)可以這樣寫import re def clean_price(raw_price: str): if not raw_price: return None match re.search(r\d(?:,\d{3})*(?:\.\d)?, raw_price) if not match: return None return float(match.group(0).replace(,, ))4.3 從臟數(shù)據(jù)里總結(jié)邊界清單實際項目里我會把每遇到一種新臟數(shù)據(jù)都寫成一條測試。下面是一份我常用的清洗層邊界清單空字符串或None統(tǒng)一返回None或默認(rèn)值絕不拋異常。逗號和空格分隔價格里的千分位逗號、空格都要移除后再轉(zhuǎn)數(shù)值。中文標(biāo)點日期里的“年、月、日”、價格里的“”符號需要剝離。單位混雜“1.2萬”“1,000”“約500”這類模糊表達要么定義規(guī)則轉(zhuǎn)為數(shù)值要么返回None。標(biāo)簽殘留描述字段從網(wǎng)頁抓下來帶著a、br標(biāo)簽需要strip_html。與其在代碼里靠感覺處理不如把這些全部列成測試用例。每遇到一種新臟數(shù)據(jù)先加用例讓它失敗再改代碼讓它通過——這就是測試驅(qū)動清洗函數(shù)的方式。4.4 日期清洗示例再補一個日期清洗的常見例子目標(biāo)是支持“2024年12月1日”這種中文格式輸出“2024-12-01”import re def clean_date(raw: str): if not raw: return None match re.search(r(\d{4})\s*年\s*(\d{1,2})\s*月\s*(\d{1,2})\s*日, raw) if not match: return None year, month, day match.groups() return f{year}-{int(month):02d}-{int(day):02d}測試用例pytest.mark.parametrize(raw,expected, [ (2024年12月1日, 2024-12-01), (發(fā)布于2024年1月5日, 2024-01-05), (, None), ]) def test_clean_date(raw, expected): assert clean_date(raw) expected注意如果網(wǎng)站上給的是“2024-12-01”這種標(biāo)準(zhǔn)ISO格式目前這個實現(xiàn)會返回None。這是合理的測試會明確記錄這個函數(shù)支持什么、不支持什么。后面真要支持ISO格式再加一條用例改動也會很安全。5. 入庫測試用內(nèi)存SQLite檢驗重復(fù)寫入與字段正確性5.1 入庫層最常見的三類錯誤解析和清洗都過了數(shù)據(jù)終于到了入庫這一步。很多人覺得存數(shù)據(jù)庫還不簡單實際上沒有測試保護的入庫邏輯問題一點不比前兩層少同一個URL爬了兩次數(shù)據(jù)庫里出現(xiàn)兩條幾乎一樣的記錄。表結(jié)構(gòu)和字段對不上數(shù)據(jù)插進去后列錯位。類型沒轉(zhuǎn)換好把字符串塞進數(shù)值字段有的庫直接報錯。多任務(wù)并發(fā)時連接沒處理好數(shù)據(jù)互相覆蓋。入庫測試要回答的問題是數(shù)據(jù)交給存儲層之后數(shù)據(jù)庫的狀態(tài)是否符合預(yù)期重復(fù)寫入會不會產(chǎn)生臟數(shù)據(jù)5.2 fixture構(gòu)建內(nèi)存SQLite與一次性表結(jié)構(gòu)我的建議是測試環(huán)境用SQLite的內(nèi)存模式:memory:不碰真實數(shù)據(jù)。原因很實際測試需要快速、可重復(fù)、不污染數(shù)據(jù)。內(nèi)存SQLite連文件都不用創(chuàng)建每個用例結(jié)束后自動消失互不干擾。import sqlite3 import pytest from spider.storage import create_schema, save_book pytest.fixture def conn(): conn sqlite3.connect(:memory:) create_schema(conn) yield conn conn.close() def test_save_book_creates_one_row(conn): save_book(conn, { title: Python編程從入門到實踐, price: 89.0, author: Eric Matthes, url: http://books.example.com/1, }) rows conn.execute(SELECT title, price, author FROM books).fetchall() assert len(rows) 1 assert rows[0] (Python編程從入門到實踐, 89.0, Eric Matthes)注意這里的關(guān)鍵pytest的fixture在每個測試前創(chuàng)建表結(jié)構(gòu)、結(jié)束后關(guān)閉連接這是測試隔離的基礎(chǔ)。如果多個測試共享同一個數(shù)據(jù)庫數(shù)據(jù)就會互相干擾斷言就很難寫了。表結(jié)構(gòu)我用URL唯一約束def create_schema(conn): conn.execute( CREATE TABLE IF NOT EXISTS books ( id INTEGER PRIMARY KEY AUTOINCREMENT, url TEXT UNIQUE, title TEXT, price REAL, author TEXT ) ) conn.commit()5.3 冪等寫入與UPSERT測試生產(chǎn)環(huán)境里爬蟲任務(wù)經(jīng)常需要重復(fù)執(zhí)行今天跑完明天再跑調(diào)試時也可能跑好幾遍。如果入庫邏輯不處理重復(fù)數(shù)據(jù)庫很快就會堆滿垃圾。所以我會專門為“冪等性”寫一條測試def test_save_same_book_twice_only_stores_once(conn): book { title: 測試書, price: 10.0, author: 張三, url: http://books.example.com/unique, } save_book(conn, book) save_book(conn, book) count conn.execute(SELECT COUNT(*) FROM books).fetchone()[0] assert count 1如果你用的是普通INSERT第二次寫入會拋IntegrityError因為url重復(fù)測試會紅。更合理的做法是用“存在則跳過、不存在則插入”的冪等寫入def save_book(conn, book): conn.execute( INSERT OR IGNORE INTO books (url, title, price, author) VALUES (?, ?, ?, ?) , (book[url], book[title], book[price], book[author])) conn.commit()如果你希望重復(fù)爬取時更新標(biāo)題、價格等字段就要用UPSERT語義存在則更新不存在則插入def upsert_book(conn, book): conn.execute( INSERT INTO books (url, title, price, author) VALUES (?, ?, ?, ?) ON CONFLICT(url) DO UPDATE SET title excluded.title, price excluded.price, author excluded.author , (book[url], book[title], book[price], book[author])) conn.commit()對應(yīng)的測試就要斷言第一次插入一條第二次更新同一條而不新增并且價格字段被更新。5.4 測試隔離絕不碰生產(chǎn)數(shù)據(jù)再補一點實戰(zhàn)經(jīng)驗在測試?yán)锉M量別碰真實數(shù)據(jù)庫。我見過有人在開發(fā)庫上直接跑測試跑完了還得手動清數(shù)據(jù)每次都心驚膽戰(zhàn)。SQLite內(nèi)存庫零成本最適合做測試。如果項目用的是MySQL或PostgreSQL測試環(huán)境也要單獨建schema或庫在fixture里做事務(wù)回滾或清表。pytest里更穩(wěn)健的做法是這樣pytest.fixture def db_conn(): conn sqlite3.connect(:memory:, check_same_threadFalse) create_schema(conn) yield conn conn.rollback() conn.close()每個用例的數(shù)據(jù)都在內(nèi)存庫里測試結(jié)束后直接丟庫互不影響。這樣無論你跑多少次測試都不需要擔(dān)心誤刪生產(chǎn)數(shù)據(jù)。6. 紅-綠-重構(gòu)一次小型TDD實戰(zhàn)演示6.1 從ImportError開始先寫一條失敗測試很多零基礎(chǔ)同學(xué)聽說TDD覺得“先寫測試再寫代碼”很反直覺。我用一個特別小的例子演示一下你會發(fā)現(xiàn)這套流程其實很順。需求寫一個函數(shù)從禮品卡頁面解析面額字符串“$50”為數(shù)字50。第一步不寫實現(xiàn)先寫測試from spider.parser import parse_gift_card_amount def test_parse_gift_card_amount(): assert parse_gift_card_amount($50) 50此時我連parse_gift_card_amount函數(shù)都沒建。運行pytest它會報ImportError測試失敗。這就是“紅”。6.2 最小實現(xiàn)讓測試轉(zhuǎn)綠第二步寫一個最笨的實現(xiàn)讓測試通過def parse_gift_card_amount(raw: str): return int(raw.replace($, ))運行測試通過了這就是“綠”。有人覺得這一步實現(xiàn)得太簡單沒錯TDD的哲學(xué)就是在測試約束下用最小代價搞定功能別提前設(shè)計一堆用不上的東西。6.3 補充邊界用例倒逼實現(xiàn)進化第三步回到測試?yán)镅a充邊界用例pytest.mark.parametrize(raw,expected, [ ($50, 50), ($1,000, 1000), ($50.5, 50.5), (, None), ]) def test_parse_gift_card_amount(raw, expected): assert parse_gift_card_amount(raw) expected第二條用例“$1,000”就會失敗說明當(dāng)前實現(xiàn)沒處理千分位逗號。這時候再去擴展實現(xiàn)def parse_gift_card_amount(raw: str): if not raw: return None cleaned raw.replace($, ).replace(,, ).strip() try: return float(cleaned) except ValueError: return None所有用例都通過。整個過程下來你既擁有了一個被測試保護的函數(shù)又讓實現(xiàn)被需求逐步驅(qū)動著長出來而不是一開始就憑感覺寫一大堆代碼。這套節(jié)奏用在正式爬蟲項目里體會會更明顯。6.4 日常跑測試的節(jié)奏與應(yīng)對紅測試的心態(tài)項目搭好之后我日常的節(jié)奏是爬蟲代碼有改動先跑pytest tests/ -v看是否全綠。出現(xiàn)紅的時候第一反應(yīng)不是“改代碼把測試弄綠”而是先想清楚是測試預(yù)期過時了還是代碼改壞了兩者處理方式完全不同。網(wǎng)站改版了先打開fixtures里的HTML樣本看哪些字段變了先改測試再改代碼順序不能反。這里有個很容易搞反的地方很多人看到測試紅了就趕緊刪用例說“這個場景不重要”。我的建議是別急先搞清楚為什么紅。測試紅了恰恰說明頁面樣本、解析邏輯、預(yù)期結(jié)果三者之間有沖突這正是調(diào)試的好時機。直接刪用例等于關(guān)掉警報器風(fēng)險只會更大。最后分享一個我自己的習(xí)慣每次頁面改版我會把抓到的HTML另存一份到tests/fixtures文件名帶上日期。這些HTML樣本比任何文檔都真實地記錄了網(wǎng)站的變化軌跡。測試驅(qū)動爬蟲這套做法前期會多花一點時間寫用例但回報是長期的——你的爬蟲不再是“跑完就扔”的一次性腳本而是可以放心維護、隨時修改的工程。這個轉(zhuǎn)變才是爬蟲入門到進階真正的分水嶺。