先聊點(diǎn)實(shí)在的。Django項(xiàng)目寫測試早期大家基本靠unittest和setUpTestData撐場面后來pytest以極其舒服的 fixture 和斷言風(fēng)格席卷 Python 圈Django 官方文檔里也專門給了兼容方案。但真正讓 pytest 在 Django 項(xiàng)目里“落地生根”的是pytest-django這個(gè)插件。這些年我在好幾個(gè)中型 Django 項(xiàng)目里把測試體系從零搭起來也從 unittest 遷移到 pytest-django踩過不少坑也總結(jié)出一套比較順手的用法。這篇東西不打算把官方文檔翻譯一遍而是按“為什么要這么用”“實(shí)際項(xiàng)目里怎么落地”“出了問題怎么排查”這條線把 pytest-django 的關(guān)鍵機(jī)制、fixture、標(biāo)記、數(shù)據(jù)庫策略這些核心內(nèi)容完整過一遍適合正在搭建或重構(gòu) Django 測試體系的人參考也適合剛接觸 pytest-django 的人當(dāng)一份深度使用手冊。1. 整體設(shè)計(jì)思路pytest-django 到底幫我們解決了什么很多人在 Django 里寫測試第一個(gè)困惑是Django 自帶manage.py test為什么還要引入 pytest-django這背后其實(shí)是一套測試范式的問題先把這個(gè)想明白后面的操作才不是機(jī)械套用。1.1 從 unittest 到 pytest為什么測試代碼比測試工具更重要Django 自帶的測試框架基于 unittest寫出來的測試天然是類組織的from django.test import TestCase class UserTestCase(TestCase): def setUp(self): self.user User.objects.create(usernametest) def test_user_created(self): self.assertEqual(self.user.username, test)這套寫法沒什么不好但在實(shí)際項(xiàng)目里測試代碼多了之后有一個(gè)很現(xiàn)實(shí)的問題setUp里的對象構(gòu)造邏輯經(jīng)常要在多個(gè)測試類里重復(fù)改一個(gè)字段要全局搜索替換。pytest 的 fixture 機(jī)制把“準(zhǔn)備數(shù)據(jù)”和“執(zhí)行斷言”徹底解耦你需要什么就聲明什么import pytest from myapp.models import User pytest.fixture def user(db): return User.objects.create(usernametest) def test_user_created(user): assert user.username test從可維護(hù)性角度看fixture 是函數(shù)級的、可組合的、作用域可控的這比類繼承要優(yōu)雅得多。pytest-django 就是這座橋它讓 pytest 的 fixture 體系能夠理解 Django 的 ORM、數(shù)據(jù)庫事務(wù)、請求客戶端等機(jī)制兩邊能無縫協(xié)作。1.2 pytest-django 的核心職責(zé)拆解這個(gè)插件不是簡單地在 pytest 里注冊幾個(gè) fixture它做的事可以拆成四塊測試數(shù)據(jù)庫生命周期管理Django 要求測試跑在一個(gè)獨(dú)立的測試數(shù)據(jù)庫里pytest-django 負(fù)責(zé)在會話開始時(shí)按 Django 的配置創(chuàng)建測試庫跑完銷毀或復(fù)用。數(shù)據(jù)庫訪問策略控制Django 測試用例默認(rèn)在一個(gè)事務(wù)里跑pytest 則是函數(shù)級隔離。pytest-django 提供了django_db標(biāo)記只有標(biāo)記了才允許測試訪問數(shù)據(jù)庫這個(gè)“顯式優(yōu)于隱式”的設(shè)計(jì)能防止誤操作真庫。Django 專屬 fixtureclient、admin_client、settings、django_user_model等把 Django 的測試工具包裝成 pytest 風(fēng)格用的時(shí)候直接聲明參數(shù)即可。配置與命令行集成支持--reuse-db、--create-db、--keepdb、--nomigrations等參數(shù)讓你能控制測試庫的創(chuàng)建策略大幅提升本地和 CI 上的測試速度。一句話總結(jié)思路pytest-django 不是讓你拋棄 Django 的測試工具而是把 Django 的測試工具重新做成符合 pytest 哲學(xué)的樣子然后你可以在上面疊加自己的 fixture 層。2. 環(huán)境搭建與基礎(chǔ)配置從安裝到第一個(gè)用例落地2.1 安裝與依賴說明安裝本身沒什么特殊pip install pytest-django一行命令。但要注意它的依賴關(guān)系它會自動帶上 pytest不會自動帶 DjangoDjango 是你項(xiàng)目里已有的。建議用虛擬環(huán)境管理避免系統(tǒng) Python 被污染。裝完以后第一步是在項(xiàng)目根目錄和 manage.py 平級創(chuàng)建或修改pytest.ini寫入基礎(chǔ)配置[pytest] DJANGO_SETTINGS_MODULE myproject.settings python_files tests.py test_*.py *_tests.pyDJANGO_SETTINGS_MODULE 是這個(gè)插件唯一真正必須的配置項(xiàng)它告訴 pytest-django 使用哪個(gè) Django 配置。如果漏了你運(yùn)行 pytest 的時(shí)候會直接報(bào)錯(cuò)ImproperlyConfigured提示你設(shè)置這個(gè)環(huán)境變量。除了放在 pytest.ini 里也可以在命令行指定DJANGO_SETTINGS_MODULEmyproject.settings pytest但寫成配置文件里才是正道不然團(tuán)隊(duì)里每個(gè)人跑測試都要在心里記著這個(gè)環(huán)境變量遲早有人忘記。2.2 conftest.py 的作用與第一個(gè)自定義 fixturepytest 的 fixture 發(fā)現(xiàn)機(jī)制依賴conftest.py。這個(gè)文件放在哪一層里面的 fixture 就作用在哪一層。項(xiàng)目根目錄的 conftest.py 里的 fixture 全局可見子應(yīng)用目錄下的 conftest.py 只對該目錄下的測試可見。我一般會在根目錄 conftest.py 里放兩類東西一個(gè)是跨測試的通用工廠函數(shù)另一個(gè)是 pytest-django 原生 fixture 的二次封裝。舉個(gè)例子如果項(xiàng)目里需要頻繁創(chuàng)建帶完整關(guān)聯(lián)數(shù)據(jù)的訂單我可以這樣封裝import pytest from myapp.models import Order, User pytest.fixture def create_order(db): def _create_order(usernametest, amount100, **kwargs): user User.objects.create(usernameusername) return Order.objects.create(useruser, amountamount, **kwargs) return _create_order def test_order_total(create_order): order create_order(amount200) assert order.total 200這樣封裝的好處是測試代碼里不再出現(xiàn)Order.objects.create這樣冗長的構(gòu)造邏輯改字段默認(rèn)值時(shí)也只需要改一處工廠函數(shù)。注意這里 fixture 的參數(shù)是db它不是憑空出現(xiàn)的正是 pytest-django 提供的數(shù)據(jù)庫訪問 fixture后面會詳細(xì)講。寫到這里環(huán)境已經(jīng)通了可以跑第一個(gè)測試了。但只是“能跑”離“好用”還有距離接下來的內(nèi)容才是真正的關(guān)鍵pytest-django 那些 fixture 和標(biāo)記到底各自是什么意思、什么時(shí)候用哪個(gè)。3. 核心機(jī)制剖析django_db 標(biāo)記與數(shù)據(jù)庫訪問控制pytest-django 最容易被忽略但最核心的設(shè)計(jì)就是它不會自動讓你訪問數(shù)據(jù)庫。這看起來是限制其實(shí)是對你的保護(hù)。3.1 數(shù)據(jù)庫默認(rèn)禁用的理念與 db fixture在 Django 的 unittest 里Test 類跑起來就有數(shù)據(jù)庫事務(wù)包裹self.client.get()隨便調(diào)。但 pytest-django 的默認(rèn)行為是你寫的測試函數(shù)如果沒有聲明需要數(shù)據(jù)庫那它就不會去碰數(shù)據(jù)庫即使碰了也會報(bào)錯(cuò)Failed: Access to database in a test is not allowed。為什么這樣設(shè)計(jì)因?yàn)?pytest 里大量測試根本不需要數(shù)據(jù)庫比如純函數(shù)、算法邏輯、靜態(tài)代碼檢查。如果每個(gè)測試都初始化數(shù)據(jù)庫再快的機(jī)器也扛不住幾百個(gè)測試的疊加。所以 pytest-django 規(guī)定了要訪問數(shù)據(jù)庫必須在測試函數(shù)上打標(biāo)記或者使用dbfixtureimport pytest from myapp.models import User # 方式一顯式聲明 db fixture def test_user_count(db): assert User.objects.count() 0 # 方式二用 django_db 標(biāo)記 pytest.mark.django_db def test_user_count_2(): assert User.objects.count() 0兩者效果一樣。dbfixture 本質(zhì)上是內(nèi)部定義好的一個(gè) fixture它內(nèi)部會執(zhí)行django_db標(biāo)記的邏輯。個(gè)人習(xí)慣上測試函數(shù)名里帶db參數(shù)看得更直觀但用標(biāo)記可以配合參數(shù)化場景。哪種都行關(guān)鍵是你要明確知道自己寫的測試是否依賴數(shù)據(jù)庫。3.2 django_db 標(biāo)記的高級參數(shù)transaction、serialized_rollback、reset_sequencesdjango_db標(biāo)記不是簡單的開關(guān)它還能控制數(shù)據(jù)庫訪問的事務(wù)行為。在日常項(xiàng)目中最常見的是這樣幾個(gè)參數(shù)。transactionTrue。默認(rèn)情況下dbfixture 和django_db標(biāo)記會把整個(gè)測試包在一個(gè)外層事務(wù)里測試結(jié)束回滾數(shù)據(jù)不落庫。但有些測試要主動調(diào)用transaction.atomic()或者測試并發(fā)行為外層事務(wù)會把內(nèi)層提交阻塞住。這時(shí)候需要pytest.mark.django_db(transactionTrue) def test_commit_behavior(): with transaction.atomic(): User.objects.create(usernametest) # 到這里數(shù)據(jù)在數(shù)據(jù)庫里是可見的 assert User.objects.filter(usernametest).exists()注意transactionTrue會讓測試不再包在外層事務(wù)中函數(shù)里的寫入會真實(shí)落庫。所以跑完這種測試數(shù)據(jù)庫里會殘留測試數(shù)據(jù)這也是為什么要用獨(dú)立測試庫的原因之一。serialized_rollbackTrue。這個(gè)參數(shù)用于處理“測試修改了數(shù)據(jù)庫序列比如自增主鍵”的場景。默認(rèn)情況下外層事務(wù)回滾時(shí)序列不會回滾導(dǎo)致測試跑完后自增主鍵繼續(xù)遞增。如果你的測試斷言依賴主鍵 ID 的精確值可以加上serialized_rollbackTrue強(qiáng)制回滾序列pytest.mark.django_db(serialized_rollbackTrue) def test_pk_value(): user User.objects.create(usernametest) assert user.pk 1reset_sequencesTrue。在 pytest 的參數(shù)化測試中如果每個(gè)參數(shù)都新建數(shù)據(jù)默認(rèn)情況下主鍵會持續(xù)遞增。要重置每個(gè)參數(shù)的主鍵從 1 開始在pytest.mark.parametrize和django_db聯(lián)合使用時(shí)它很有用pytest.mark.django_db(reset_sequencesTrue) pytest.mark.parametrize(name, [a, b, c]) def test_create_user(name): user User.objects.create(usernamename) assert user.pk 1這三個(gè)參數(shù)在實(shí)際項(xiàng)目中不是每個(gè)都會用到transaction 常用在帶事務(wù)邏輯的測試?yán)飐erialized_rollback 和 reset_sequences 則用在斷言 ID 或序列狀態(tài)的場景。3.3 事務(wù)測試中常見的一個(gè)大坑用 pytest-django 默認(rèn)的dbfixture 時(shí)Django 的信號不會在測試結(jié)束后觸發(fā)“提交”邏輯因?yàn)闇y試本身就在一個(gè)外層事務(wù)中永遠(yuǎn)不會真正 commit。如果你依賴某個(gè)信號的post_save在 commit 后執(zhí)行比如給用戶發(fā)郵件、寫日志在dbfixture 模式下信號可能不會觸發(fā)或表現(xiàn)和線上不一致。解決辦法涉及 commit/signal 行為的測試用pytest.mark.django_db(transactionTrue)跑。我在日志系統(tǒng)測試?yán)锞筒冗^這個(gè)坑排查了半天發(fā)現(xiàn)是事務(wù)行為差異改過來就好了。這個(gè)點(diǎn)官方文檔寫得比較隱晦實(shí)際項(xiàng)目里非常容易遇到。4. 實(shí)用 fixture 全解析client、admin_client、settings、django_user_modelpytest-django 最讓人舒服的是它為 Django 的測試工具做了 pytest 化包裝。這一節(jié)把最常用的幾個(gè) fixture 全部講透。4.1 client 與 admin_client測試 HTTP 請求的正確姿勢Django 的測試客戶端django.test.Client是模擬瀏覽器請求的核心工具pytest-django 把它做成了clientfixture。用的時(shí)候直接在測試函數(shù)里聲明def test_home_page(client): resp client.get(/) assert resp.status_code 200這里有個(gè)關(guān)鍵點(diǎn)client fixture 默認(rèn)訪問數(shù)據(jù)庫嗎答案是要看請求的視圖是否碰數(shù)據(jù)庫。如果視圖內(nèi)查了 ORM而測試函數(shù)沒聲明db請求會報(bào)數(shù)據(jù)庫訪問錯(cuò)誤。所以我看很多人寫的測試是def test_home_page(client, db): resp client.get(/)這不是冗余而是明確告訴 pytest-django這個(gè)測試會通過請求間接訪問數(shù)據(jù)庫。另一種更地道的方式是用django_db標(biāo)記。加上就完事。admin_client是包裝好的 admin 后臺客戶端它自動創(chuàng)建超級用戶并登錄。適合測試 Django admin 后臺的頁面def test_admin_page(admin_client): resp admin_client.get(/admin/) assert resp.status_code 200使用 admin_client 的前提是 admin 站點(diǎn)已注冊了模型。這個(gè) fixture 內(nèi)部會用django_user_model創(chuàng)建用戶所以它會訪問數(shù)據(jù)庫測試函數(shù)要聲明db或者其內(nèi)部已聲明實(shí)際使用中把 db 加上更穩(wěn)。4.2 settings fixture臨時(shí)改配置的利器測試時(shí)經(jīng)常需要臨時(shí)改配置比如改緩存后端、關(guān)掉 Celery 任務(wù)、調(diào)整分頁大小。不要手動改 settings 對象再恢復(fù)pytest-django 提供了settingsfixture它會在測試結(jié)束自動恢復(fù)原值def test_pagination(client, settings, db): settings.PAGE_SIZE 10 resp client.get(/users/) assert len(resp.context[users]) 10注意 settings fixture 的生效范圍是測試函數(shù)內(nèi)對于override_settings能覆蓋的場景它都適用。但它不會自動同步到 Django 的 settings 模塊緩存里如果你改的是CACHES這種會建立連接池的配置測試結(jié)束后的清理要留意之前我遇到過改 CACHES 導(dǎo)致后續(xù)測試連接殘留的情況建議能用django.test.override_settings的場景優(yōu)先用 override_settings需要?jiǎng)討B(tài)改的場景再用 settings fixture。4.3 django_user_model 與 django_assert_num_queries進(jìn)階操作django_user_model返回當(dāng)前項(xiàng)目的用戶模型類方便創(chuàng)建用戶而不用直接引自定義模型def test_normal_user(django_user_model, db): user django_user_model.objects.create_user(usernamet, passwordx) assert user.is_authenticateddjango_assert_num_queries是性能測試的神器。它作為一個(gè)上下文管理器包裝代碼塊斷言執(zhí)行期間 SQL 查詢次數(shù)def test_user_list_query_count(client, django_assert_num_queries, db): with django_assert_num_queries(2): resp client.get(/users/) assert resp.status_code 200這里的 2 次查詢意味著你期望該視圖只查一次列表、一次計(jì)數(shù)或類似。如果你的視圖有 N1 查詢問題這個(gè) fixture 能立刻暴露出來。實(shí)際操作中我先用django_assert_num_queries不加參數(shù)跑一遍打印實(shí)際 SQL 數(shù)量再分析有沒有冗余查詢優(yōu)化完后把期望值寫死。這個(gè) fixture 對排查 ORM 查詢次數(shù)、驗(yàn)證 select_related/prefetch_related 是否生效非常有效。5. 數(shù)據(jù)庫策略深度調(diào)優(yōu)--create-db、--reuse-db、--keepdb 與遷移處理這是 pytest-django 提升測試速度最直接的地方。很多團(tuán)隊(duì)的測試越跑越慢很大程度是數(shù)據(jù)庫反復(fù)重建導(dǎo)致的而不是測試本身的問題。5.1 三種命令的參數(shù)對比什么時(shí)候該用哪個(gè)pytest-django 提供幾個(gè)命令行參數(shù)控制測試庫的生命周期參數(shù)作用使用場景--create-db每次運(yùn)行都重新創(chuàng)建測試數(shù)據(jù)庫默認(rèn)行為適合驗(yàn)證環(huán)境一致性但最慢--reuse-db復(fù)用上次創(chuàng)建的測試數(shù)據(jù)庫若結(jié)構(gòu)不變則不重建本地開發(fā)推薦速度提升明顯--keepdb測試結(jié)束后保留測試數(shù)據(jù)庫默認(rèn)會銷毀下次運(yùn)行直接復(fù)用配合--reuse-dbCI 里可加速默認(rèn)情況下pytest-django 每次運(yùn)行都會銷毀舊的測試庫、重新創(chuàng)建這個(gè)流程在模型多、遷移文件多的大項(xiàng)目里可能要花幾十秒甚至幾分鐘。--reuse-db的價(jià)值在本地開發(fā)時(shí)尤其明顯我沒有關(guān)掉過測試庫連續(xù)跑測試第一次初始化花 30 秒后面每次跑只要 3 秒。注意--reuse-db適合模型結(jié)構(gòu)沒有變化的場景。如果改了模型字段或遷移文件pytest-django 會檢測到測試庫結(jié)構(gòu)不匹配而自動重建所以不用擔(dān)心用了這個(gè)參數(shù)就吃舊數(shù)據(jù)。它的檢測邏輯是基于 Django 的 migration 執(zhí)行記錄不是簡單的“庫存在就不管”。5.2 禁用遷移提升速度--nomigrations 與 nomigrations 標(biāo)記另一個(gè)高度推薦的加速手段是禁用遷移。Django 每個(gè)測試庫創(chuàng)建時(shí)默認(rèn)會跑一遍所有遷移文件如果項(xiàng)目有幾百個(gè)遷移這一步占用了大量時(shí)間。--nomigrations參數(shù)讓 pytest-django 直接用migrate --run-syncdb的方式建表只建當(dāng)前模型對應(yīng)的表不執(zhí)行歷史遷移文件。pytest --nomigrations實(shí)測下來一個(gè)有約 200 個(gè)遷移文件的項(xiàng)目開啟--nomigrations后測試庫初始化時(shí)間從 50 秒降到 5 秒左右效果立竿見影。但代價(jià)是遷移文件中通過RunPython做的數(shù)據(jù)遷移不會執(zhí)行。比如某個(gè)遷移把舊數(shù)據(jù)格式轉(zhuǎn)換成了新格式而你的測試數(shù)據(jù)創(chuàng)建邏輯沒有覆蓋這個(gè)轉(zhuǎn)換測試環(huán)境和本地開發(fā)環(huán)境就會出現(xiàn)差異。我的建議是本地開發(fā)開啟--nomigrationsCI 上跑一次完整的遷移流程兩者互補(bǔ)。5.3 并發(fā)跑測試的注意事項(xiàng)用 pytest-xdist 配合 pytest-django 并行跑測試時(shí)多個(gè) worker 會共享同一個(gè)測試數(shù)據(jù)庫。dbfixture 默認(rèn)每個(gè)測試一個(gè)事務(wù)并行時(shí)不會有數(shù)據(jù)沖突因?yàn)槭聞?wù)是隔離的。但使用transactionTrue的測試在并發(fā)時(shí)可能會出現(xiàn)寫沖突建議把這類測試挑出來單獨(dú)跑或者給它們標(biāo)記為串行pytest -n 4 --distloadgroup先規(guī)劃好哪些測試可以并行哪些必須串行再啟動并發(fā)。我見過有團(tuán)隊(duì)一上來就-n auto結(jié)果一堆事務(wù)型測試互相干擾排查了半天才意識到是并行導(dǎo)致的。6. 進(jìn)階實(shí)戰(zhàn)異步測試、遷移本地化與 CI 集成6.1 異步 Django 視圖與 pytest-django 的異步支持Django 3.1 之后支持異步視圖pytest-django 也隨之增加了異步測試支持。如果你寫了async def test_xxx的測試函數(shù)需要用到pytest.mark.asyncio配合async_db或django_db_async來處理數(shù)據(jù)庫import pytest pytest.mark.asyncio pytest.mark.django_db() async def test_async_view(async_client, db): resp await async_client.get(/async-view/) assert resp.status_code 200異步測試?yán)锊荒茉僦苯佑猛降膁bfixture要用async_db或django_db標(biāo)記配合pytest.mark.asyncio。異步客戶端async_client是 pytest-django 提供的封裝了 Django 異步測試客戶端。這個(gè)領(lǐng)域的坑比同步多得多最典型的是異步測試?yán)锏?ORM 查詢必須用sync_to_async包裹或使用aget、acreate這類異步 API。寫異步測試前先確認(rèn)模型 API 是兼容異步的Django 官網(wǎng)說async安全不是絕對的像queryset.filter()這種惰性查詢依然要在sync_to_async里調(diào)用。6.2 按需創(chuàng)建測試庫databases 標(biāo)簽與 multi-db 支持多數(shù)據(jù)庫項(xiàng)目主從、分庫里pytest-django 默認(rèn)只創(chuàng)建DATABASES配置里的 default 庫。要測試其他庫需要在django_db標(biāo)記里指定pytest.mark.django_db(databases[default, replica]) def test_multi_db(): # 同時(shí)訪問兩個(gè)庫 ...如果不指定測試訪問非 default 庫時(shí)會報(bào)數(shù)據(jù)庫未配置錯(cuò)誤。多數(shù)據(jù)庫場景還容易遇到事務(wù)和序列的問題建議明確畫出每個(gè)測試到底使用哪些庫別讓一個(gè)測試默默訪問所有庫速度慢且容易出錯(cuò)。6.3 CI 集成GitLab CI 與 GitHub Actions 的配置要點(diǎn)把 pytest-django 集成進(jìn) CI核心是保證每次跑測試的環(huán)境一致同時(shí)盡量復(fù)用 DB 以提速。GitLab CI 的示例配置.gitlab-ci.yml片段test: stage: test image: python:3.11-slim services: - postgres:15 variables: POSTGRES_DB: test_db POSTGRES_USER: postgres POSTGRES_PASSWORD: postgres DJANGO_SETTINGS_MODULE: myproject.settings before_script: - pip install -r requirements.txt - apt-get update apt-get install -y libpq-dev script: - pytest --create-db --nomigrations -n 4注意 CI 上每次都是從零開始--create-db可以保證結(jié)構(gòu)一致性。如果服務(wù)里每次都掛一個(gè)新的 Postgres那--reuse-db意義不大直接用--create-db。GitHub Actions 的思路類似用一個(gè) PostgreSQL 服務(wù)容器然后跑 pytest。關(guān)鍵是DJANGO_SETTINGS_MODULE必須在 CI 環(huán)境變量里設(shè)好否則 pytest-django 同樣會報(bào) ImproperlyConfigured。6.4 局部禁用遷移的標(biāo)記需要的時(shí)候再細(xì)調(diào)全局--nomigrations太一刀切pytest-django 提供了標(biāo)記級別的nomigrationspytest.mark.nomigrations def test_something(): ...這個(gè)標(biāo)記讓 pytest-django 只對當(dāng)前測試的數(shù)據(jù)庫創(chuàng)建時(shí)使用--run-syncdb而其他測試仍然走完整遷移。適合只驗(yàn)證模型層邏輯而不用管歷史遷移數(shù)據(jù)的測試。和全局參數(shù)一樣它最大的作用是加速但代價(jià)是缺少數(shù)據(jù)遷移的歷史狀態(tài)。在復(fù)雜項(xiàng)目里把這些標(biāo)記用在純新增模型的領(lǐng)域邏輯測試上是安全的。7. 常見問題與排查技巧實(shí)錄7.1 報(bào)錯(cuò) ImproperlyConfiguredDJANGO_SETTINGS_MODULE 沒有設(shè)置這是最常遇到的錯(cuò)誤。pytest-django 找不到 Django 配置就直接拋異常。解決思路依次排查pytest.ini 里是否寫了DJANGO_SETTINGS_MODULEconftest.py 是否被 pytest 正確加載可以在 conftest.py 里 print 一下驗(yàn)證環(huán)境變量是否被覆蓋有些 IDE 的測試 runner 會注入自己的 DJANGO_SETTINGS_MODULE一個(gè)容易忽略的細(xì)節(jié)conftest.py 里如果 import 了 Django 模型模塊而 DJANGO_SETTINGS_MODULE 還沒有設(shè)置可能在導(dǎo)入階段就報(bào)錯(cuò)。最好在 pytest.ini 配置好后先跑一個(gè)最簡單的不依賴 Django 的測試確認(rèn) pytest 本身正常再疊加 Django 相關(guān)測試。7.2 數(shù)據(jù)庫訪問被禁止Access to database in a test is not allowed這個(gè)報(bào)錯(cuò)幾乎每個(gè) pytest-django 用戶都遇到過。原因就是測試函數(shù)訪問了數(shù)據(jù)庫但沒有聲明db或django_db。排查方法查看調(diào)用鏈里哪一步觸發(fā)了 ORM 查詢在測試函數(shù)參數(shù)里加上db或用pytest.mark.django_db如果是 fixture 內(nèi)部訪問了數(shù)據(jù)庫確保該 fixture 返回前聲明了db或使用django_db注意如果在 conftest.py 里定義了一個(gè)內(nèi)部訪問數(shù)據(jù)庫的 fixture而該 fixture 聲明為session或module作用域dbfixture 默認(rèn)是函數(shù)作用域此時(shí)會報(bào)作用域沖突。解決辦法是把這個(gè) fixture 也改成函數(shù)級作用域或者寫一個(gè) session 級且內(nèi)部自行創(chuàng)建事務(wù)的 fixture。這是我自己踩過的一個(gè)比較隱蔽的坑。7.3 測試數(shù)據(jù)庫被鎖定could not connect to databasePostgres 下有時(shí)會報(bào)could not connect to database test_db ... database is being accessed by other users多半是上次測試沒清理干凈進(jìn)程。最直接的急救辦法pytest --create-db強(qiáng)制重建測試庫。如果還是報(bào)錯(cuò)手動進(jìn) Postgres 刪除殘留測試庫DROP DATABASE IF EXISTS test_db;在本地開發(fā)中這個(gè)現(xiàn)象經(jīng)常出現(xiàn)在 IDE 的調(diào)試進(jìn)程把持了數(shù)據(jù)庫連接時(shí)。關(guān)掉所有占用連接的進(jìn)程再跑就好。7.4 測試數(shù)據(jù)殘留為什么我跑完測試開發(fā)庫里多了數(shù)據(jù)這通常是因?yàn)槟阌昧藅ransactionTrue的標(biāo)記以及測試?yán)镲@式調(diào)用了create之后外層沒有回滾。排查關(guān)鍵確認(rèn)測試庫配置用的是獨(dú)立的test_前綴或獨(dú)立庫名不要和開發(fā)庫共用一個(gè)謹(jǐn)慎使用transactionTrue無必要就不要用斷言數(shù)據(jù)變化時(shí)優(yōu)先用assert而不是直接打庫查看實(shí)踐中把 DATABASES 配置里的TEST字典顯式寫清楚比如DATABASES { default: { ENGINE: django.db.backends.postgresql, NAME: myproject_dev, TEST: {NAME: myproject_test}, } }這樣即使誤操作也不會污染開發(fā)庫。7.5 參數(shù)化與數(shù)據(jù)庫組合時(shí)的性能陷阱pytest.mark.parametrize和dbfixture 配合時(shí)pytest 會在每個(gè)參數(shù)上都跑一遍測試每個(gè)參數(shù)都會啟動一個(gè)事務(wù)數(shù)據(jù)準(zhǔn)備成本會成倍增長。對于需要大量數(shù)據(jù)的測試建議把數(shù)據(jù)準(zhǔn)備放到 session 級或 module 級 fixture 中函數(shù)級只做輕量操作。示例import pytest pytest.fixture(scopemodule) def django_db_setup(django_db_setup, django_db_blocker): with django_db_blocker.unblock(): User.objects.bulk_create([User(usernamefu{i}) for i in range(1000)]) pytest.mark.django_db pytest.mark.parametrize(name, [u1, u2, u3]) def test_user_exists(name): assert User.objects.filter(usernamename).exists()這種模式下數(shù)據(jù)只準(zhǔn)備一次參數(shù)化只做查詢斷言速度會快很多。8. 幾個(gè)值得記住的小技巧與擴(kuò)展建議在項(xiàng)目里用了這么久最后分享幾個(gè)錦上添花的小技巧。第一把 pytest-django 的 fixture 分層組織。我在項(xiàng)目里通常這樣分三層基礎(chǔ)層pytest-django 自帶的db、client、settings業(yè)務(wù)層conftest.py 里定義的create_user、create_order等工廠 fixture場景層組合多個(gè)業(yè)務(wù) fixture 封裝成“帶權(quán)限的用戶”“帶訂單的店鋪”等復(fù)合 fixture這樣測試代碼里幾乎不出現(xiàn) ORM 創(chuàng)建對象的代碼絕大多數(shù)測試能壓縮到 5 行以內(nèi)。第二用 pytest 的--reuse-db和--nomigrations結(jié)合本地測試體驗(yàn)會好非常多。我通常直接寫進(jìn) pytest.ini[pytest] addopts --reuse-db --nomigrations DJANGO_SETTINGS_MODULE myproject.settings這樣每個(gè)開發(fā)者 clone 項(xiàng)目后第一次跑測試會自動建庫之后每次都在秒級啟動。CI 上則單獨(dú)用--create-db保證干凈環(huán)境。第三對測試數(shù)據(jù)庫做合理命名和定期清理。Postgres 數(shù)據(jù)庫數(shù)量多了以后垃圾測試庫會占磁盤?？梢詫憘€(gè)小腳本定期刪掉test_*前綴的庫配合 CI 和本地開發(fā)使用。第四結(jié)合 coverage 和 pytest-cov 統(tǒng)計(jì)測試覆蓋度。pytest-django 和 pytest-cov 兼容得很好pytest --covmyapp --cov-reportterm-missing這能幫你快速定位哪些模塊測試覆蓋不足值得加入 CI 的門禁指標(biāo)。pytest-django 看起來只是個(gè)插件但它決定了 Django 項(xiàng)目的測試體驗(yàn)上限。把它的 fixture 體系、數(shù)據(jù)庫策略、標(biāo)記邏輯理解透你會發(fā)現(xiàn)寫測試這件事本身變得輕松很多——測試不再是一堆重復(fù)代碼的堆疊而是一套可復(fù)用、可維護(hù)、能快速反饋迭代質(zhì)量的工具鏈。希望這篇內(nèi)容對你的 Django 測試之旅有幫助。