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