本文首發於公眾號：Hunter後端
原文連結：Django筆記三十六之單元測試彙總介紹
Django 的單元測試使用了 Python 的標準庫：unittest。
在我們建立的每一個 application 下面都有一個 tests.py 檔案，我們透過繼承 django.test.TestCase 編寫我們的單元測試。
本篇筆記會包括單元測試的編寫方式，單元測試操作流程，如何複用資料庫結構，如何測試介面，如何指定 sqlite 作為我們的單元測試資料庫等
以下是本篇筆記目錄：
- 單元測試示例、使用和介紹
- 單元測試流程介紹
- 單元測試的執行命令
- 複用測試資料庫結構
- 判斷函式
- 介面的測試
- 標記測試
- 單元測試配置
- 使用 SQLite 作為測試資料庫
1、單元測試示例、使用和介紹
首先我們編寫 blog/tests.py 檔案，建立一個簡單的單元測試：
from django.test import TestCase
from blog.models import Blog
class BlogCreateTestCase(TestCase):
def setUp(self):
Blog.objects.create(name="Python", tag_line="this is a tag line")
def test_get_blog(self):
blog = Blog.objects.get(name="Python")
self.assertEqual(blog.name, "Python")
以上是一個很簡單的單元測試示例，接下來我們執行這個單元測試：
python3 manage.py test blog.tests.BlogCreateTestCase.test_get_blog
執行之後可以看到控制檯會輸出一些資訊，如果沒有報錯，說明我們的這個單元測試成功執行。
在 BlogCreateTestCase 中，這個單元測試繼承了 django.test.TestCase，我們在 setUp() 函式中執行一些操作，這個操作會在執行某個測試，比如 test_get_blog() 前先執行。
我們執行的是 test_get_blog() 函式，這裡的邏輯是先獲取一個 blog 示例，然後透過 assertEqual() 函式判斷兩個輸入的值是否相等，如果相等，則單元測試透過，否則會報失敗的錯誤。
2、單元測試流程介紹
首先我們看一下 settings.py 中的資料庫定義：
# hunter/settings.py
DATABASES = {
'default': {
'ENGINE': "django.db.backends.mysql",
'NAME': "func_db",
"USER": "root",
"PASSWORD": "123456",
"HOST": "192.168.1.9",
"PORT": 3306,
},
}
當我們執行下面這個命令之後：
python3 manage.py test blog.tests.BlogCreateTestCase.test_get_blog
系統會去 default 這個資料庫的連線地址，建立一個新的資料庫，資料庫名稱為當前資料庫的名稱加上 test_ 字首。
比如我們連線的正式資料庫名稱為 func_db，那麼測試資料庫名為 test_func_db。
建立該資料庫之後，系統會將當前系統所有的 migration 都執行一遍到測試資料庫，然後依據我們單元測試的邏輯，比如 setUp() 中對資料的初始化，以及 test_get_blog() 中對資料的獲取和比較操作執行一遍邏輯。
這個流程結束之後，系統會自動刪除剛剛建立的測試資料庫，至此，一個單元測試執行的流程就結束了。
3、單元測試的執行命令
執行單個單元測試
上面我們執行的單元測試的命令精確到了類中的函式，我們也可以直接執行某個單元測試，比如我們的 BlogCreateTestCase 內容如下：
class BlogCreateTestCase(TestCase):
def setUp(self):
Blog.objects.create(name="Python", tag_line="this is a tag line")
def test_get_blog(self):
print("test_get_blog")
def test_get_blog_2(self):
print("test_get_blog_2")
我們直接執行命令到這個單元測試：
python3 manage.py test blog.tests.BlogCreateTestCase
那麼系統就會執行 BlogCreateTestCase 下 test_get_blog 和 test_get_blog_2 這兩個函式。
執行單元測試檔案
再往上一層，我們可以執行某個單元測試的檔案，比如該 tests.py 內容如下：
# blog/tests.py
class BlogCreateTestCase(TestCase):
def setUp(self):
Blog.objects.create(name="Python", tag_line="this is a tag line")
def test_get_blog(self):
print("test_get_blog")
class BlogCreateTestCase2(TestCase):
def test_get_blog_2(self):
print("test_get_blog_2")
當我們執行：
python3 manage.py test blog.tests
系統就會將 tests.py 中 BlogCreateTestCase 和 BlogCreateTestCase2 這兩個單元測試都執行一遍。
執行系統所有單元測試
如果我們想要統一執行系統全部單元測試，可以直接如下操作：
python3 manage.py test
單元測試查詢邏輯
當我們執行上面那條命令的時候，系統是如何查詢處測試檔案的呢？
系統會搜尋目錄下所有 test 開頭的資料夾或者檔案，如果是資料夾，則繼續尋找資料夾下 test 開頭的檔案，對於每個 test 開頭的檔案，找到繼承了 django.test.TestCase 的類，然後執行每個開頭名為 test 的類函式。
接下來我們舉幾個示例，假設我們在 blog 的目錄下有這樣的結構：
blog/
test_123/
no_test.py
test_ok.py
tests.py
tests/
tests.py
test_123.py
no_test/
test_123.py
test.py
test_123.py
no_test.py
在上面這個目錄結構下，系統會去搜尋 test_123 和 tests 資料夾下 test 開頭的檔案，以及 blog 下的 test.py、test_123.py，尋找其中繼承了 django.test.TestCase 的類作為單元測試然後執行。
在這裡，比如 test_123/no_test.py 這個檔案就不會被判定為測試檔案，因為它名稱不是 test 開頭的。
而在 test 開頭的測試檔案中，如果一個類繼承了 django.test.TestCase，但是它的類函式並不是以 test 開頭的，這樣的函式也不會被執行，比如：
class BlogCreateTestCase(TestCase):
def setUp(self):
Blog.objects.create(name="如何Python", tag_line="this is a tag line")
def test_ok(self):
print("12344444............")
self.assertEqual(1, 1)
def no_test(self):
print("no test")
比如上面這個單元測試，test_ok 這個類函式就會被作為單元測試的一部分，而 no_test 則不會被執行。
如果測試檔案較多，為了統一管理，我們可以都放在 application 下的 tests 資料夾下，比如：
blog/
tests/
test_1.py
test_2.py
test_3.py
4、複用測試資料庫結構
當我們寫完一個功能，然後編寫這個功能的單元測試，緊接著去測這個單元測試，系統就會去建立一個資料庫，然後執行所有的 migration，然後執行單元測試邏輯，執行結束之後會刪掉該測試資料庫。
在我們的專案中，如果維護到了後期，擁有的 migration 較多，每次執行單元測試都要刪掉然後重建資料庫，在時間上是一個很大的消耗，那麼我們如何在執行完一個單元測試之後儲存當前的測試資料庫用於下一次執行呢。
那就是使用 --keepdb 引數。
按照前面的邏輯，我們的測試資料庫會在 DATABASES 中定義的資料庫地址新建一個資料庫，我們可以使用 --keepdb 執行這樣的操作：
python3 manage.py test --keepdb blog.tests.BlogCreateTestCase
加上 --keepdb 引數之後，執行單元測試結束之後，我們可以透過 workbench 或者 navicat 等工具去該資料庫地址檢視，會多出一個名為 test_fund_db 的資料庫，那就是我們執行單元測試之後沒有刪除的測試資料庫。
當我們下次再執行這個或者其他單元測試的時候，可以發現執行的時間就變得很快了，而且在控制檯會輸出這樣一條資訊：
Using existing test database for alias 'default'...
意思就是使用已經存在的測試資料庫。
而不加 --keepdb 的時候，輸出的是：
Creating test database for alias 'default'...
表示的是正在建立新的測試資料庫。
注意： 雖然單元測試結束之後資料庫的結構還會保留，但是在單元測試中我們建立的資料還是會被刪除。這個僅限於在單元測試中建立的資料，透過 migration 初始化的資料還是存在資料庫中。
5、判斷函式
在介紹測試介面前，我們先介紹一下幾個判定函式。
self.assertEqual
這個函式接收三個引數，前兩個引數用於比較是否相等，第三個引數為 msg，用於在前兩個引數不相等時報出的錯誤資訊，但是可不傳，預設為 None。
比如我們這樣操作：
self.assertEqual(Blog.objects.count(), 20, msg="blog count error")
self.assertEqual(Blog.objects.count(), 20)
如果前兩個引數不相等則單元測試會不透過。
self.assertTrue
這個函式接收兩個引數，前一個引數是一個表示式，後一個引數是 msg，也是用於前一個引數不為 True 的時候報出的錯誤資訊，可不傳，預設為 None。
我們可以這樣操作：
self.assertTrue(Blog.objects.filter(name="Python").exists(), "Pyrhon blog not exists")
self.assertTrue(Blog.objects.filter(name="Python").exists())
同樣，如果表示式引數不為 True，則單元測試不會透過。
self.assertIn
接收三個引數，如果第二個引數不包含第一個引數，則會報錯，比如：
self.assertIn(6, [1,2,3], "not in list")
self.assertIn("a", "def", "not in string")
self.assertIsNone
介面兩個引數，表示如果傳入的引數為 None 則透過單元測試：
a = None
self.assertIsNone(a)
對於 assertEqual、 assertTrue、assertIn、assertIsNone 還有對應的相反意義的函式
- assertNotEqual 表示判定兩者不相等
- assertFalse 表示判定表示式為 False
- assertNotIn 表示判定後者不包含前者
- assertIsNotNone 表示判定不為 None
這裡還有一些判定大於、小於、大於等於、小於等於的函式，這裡就不做多介紹了 assertGreater、assertLess、assertGreaterEqual、assertLessEqual
self.fail(msg="failed testcase")
如果我們希望在某些判斷條件下直接讓單元測試不透過，可以直接使用 self.fail() 函式，比如：
a = 1
b = 2
if a < b:
self.fail(msg="a < b")
6、介面的測試
在上面我們的單元測試中，我們使用的只是簡單的對於 model 的建立查詢和驗證，但是一般來說，除了測試系統的工具類函式，我們常用到的測試用途是測試和驗證介面的邏輯。
在介紹如何對介面進行測試前，一下 model_mommy 庫。
model_mommy 庫
這是個可以模擬 model 資料的庫，它有什麼用處呢，比如我們想建立幾條 model 的資料，但是不關心一些必填欄位的值，或者只想指定某幾個欄位特定的值，或者想批次建立某個 model 的資料。
首先我們引入這個庫：
pip3 install model_mommy
使用 model_mommy 來建立模擬資料：
from model_mommy import mommy
blog_1 = mommy.make(Blog, name="Python")
這樣我們就建立了一條資料，這個時候如果我們列印出 blog_1 的內容，可以發現 Blog 的有預設值的欄位都被預設值填充，無預設值的都會被無意義資料填充
print(blog_1.__dict__)
# 'id': 4, 'name': 'Python', 'tag_line': 'sIDENcYqKVwESvEUAwZGIVtGdWHhKyNNoDzoaZCdDuqQuIKCkwazqwfcNEEtzfcoZeEnVVDiVLzAhhOuYsxiuKUOVFifUimnCLbMNHMpYLYxHCVSVfiggeBQhmRPFuIUwiKDUSDZztzQzFlKfcSxdnewsekQBzlCuMZLVPyOrfTXYWgPIkBhytzBkcMbpvCvidSETxZRjWeeEBPLELHpHYOmKgKHdNxrmjjLlewGWKTLQNFPFWOGndzncghTEcuFnEfRQvGgXcsPTfaGAHDDqPGyNeerTmOHDTUmnWmzHIXF', 'char_count': 0, 'is_published': 0, 'pub_datetime': None}
或者我們想批次建立二十條 Blog 的資料，我們可以透過 _quantity 引數這樣操作：
mommy.make(Blog, _quantity=20)
Client() 呼叫介面
呼叫介面用到的函式是 Client()
假設我們想要呼叫登入介面，我們可以如下操作：
from django.test import Client
url = "/users/login"
c = Client()
response = c.post(url, data={"username": "admin", "password": "123456"}, content_type="application/json")
self.assertEqual(response.json().get("code"), 0)
使用單元測試而不是使用 postman 呼叫有一個好處就是我們不用把後端服務啟動起來，所以這裡的 url 相應的也不用加上 ip 地址或者域名。
呼叫介面還有另一種方式，就是在繼承了 django.test.TestCase 的單元測試中直接使用 self.client，它與例項化 Client() 後的直接作用效果是一樣的，都可以用來呼叫介面。
那為什麼要使用 self.client 呢，是為了自動儲存登入介面的 session。
比如對於 /users/user/info 這個需要登入後才能訪問到的使用者資訊介面，我們就可以使用 self.client 在 setUp() 初始化資料的時候先進行登入操作，接著就可以以已登入狀態訪問使用者資訊介面了。
class UserInfoTestCase(TestCase):
def setUp(self):
username = "admin"
password = make_password("123456")
User.objects.create(username=username, password=password)
url = "/users/login"
response = self.client.post(url, data={"username": "admin", "password": "123456"}, content_type="application/json")
resp_data = response.json()
print("login...")
self.assertEqual(resp_data.get("code"), 0)
def test_user_info(self):
url = "/users/user/info"
response = self.client.post(url)
print(response.json())
如果系統大部分介面都需要以登入狀態才能訪問，我們甚至可以將登入操作寫入一個基礎類，其他的單元測試都繼承這個類，這樣就不需要重複編寫登入的介面了：
class BaseTestCase(TestCase):
def setUp(self):
username = "admin"
password = make_password("123456")
User.objects.create(username=username, password=password)
url = "/users/login"
response = self.client.post(url, data={"username": "admin", "password": "123456"}, content_type="application/json")
resp_data = response.json()
print("login...")
self.assertEqual(resp_data.get("code"), 0)
class UserInfoTestCase(BaseTestCase):
def test_user_info(self):
url = "/users/user/info"
response = self.client.post(url)
print(response.json())
class TestCase2(BaseTestCase):
def test_case(self):
url = "/xx/xxx"
response = self.client.post(url)
print(response.json())
7、標記測試
一般來說，我們的單元測試是都要全部透過才能上線進入生產環境的，但是某些情況下，我們對系統只進行了少部分的修改，或者說只需要測試某些特定的重要功能就可以上線，這種情況下可以給我們的測試用例打上 tag，這樣在測試的時候就可以挑選特定的單元測試，透過即可上線。
這個 tag 可以打到一個單元測試上，也可以打到某個單元測試的函式上，比如我們有三個標記，fast，slow，core，以下是幾個單元測試：
from django.test import tag
class SingleTestCase(TestCase):
@tag("fast", "core")
def test_1(self):
print("fast, core from SingleTestCase.test_1")
@tag("slow")
def test_2(self):
print("slow from SingleTestCase.test_2")
@tag("core")
class CoreTestCase(TestCase):
def test_1(self):
print("core from CoreTestCase")
然後我們可以透過 --tag 指定標記的單元測試：
python3 manage.py test --keepdb --tag=core
python3 manage.py test --keepdb --tag=core --tag=slow
8、單元測試配置
編碼配置
在前面我們的資料庫連結中，並沒有指定資料庫的編碼，而我們建立生產資料庫的時候使用的 charset 是 utf-8，而測試資料庫在建立的時候沒有指定編碼的話，預設使用的是 latin1 編碼。
這樣會造成一個問題，就是我們的單元測試在往資料庫寫入資料的時候就會因為不支援中文而導致報錯。
比如在不設定編碼的時候我們使用下面的單元測試就會報錯：
from django.test import TestCase
from blog.models import Blog
class BlogCreateTestCase(TestCase):
def setUp(self):
Blog.objects.create(name="測試資料", tag_line="this is a tag line")
def test_get_blog(self):
blog = Blog.objects.get(name="測試資料")
self.assertEqual(blog.name, "測試資料")
所以如果要指定建立的測試資料庫的編碼，我們需要加上一個配置：
DATABASES = {
'default': {
...
"TEST": {
"CHARSET": "utf8",
},
}
}
測試資料庫名稱
預設情況下，測試資料庫的名稱是 'test_' + DATABASES['default']['name']，如果我們想指定測試資料庫名稱，可以額外加一個 NAME 欄位：
DATABASES = {
'default': {
...
"TEST": {
"CHARSET": "utf8",
"NAME": "test_default_db",
},
}
}
9、使用 SQLite 作為測試資料庫
目前我們的測試資料庫是在 default 資料庫的地址新建一個資料庫，如果我們想要執行單元測試的時候直接在本地使用 SQLite 作為我們的測試資料庫，可以在 settings.py 中定義 DATABASES 的後面加上下面的定義：
import sys
if "test" in sys.argv:
DATABASES = {
"default": {
"ENGINE": "django.db.backends.sqlite3",
"NAME": os.path.join(BASE_DIR, "db.sqlite3"),
"TEST": {
"NAME": os.path.join(BASE_DIR, "test_db.sqlite3"),
}
}
}
其中，sys.argv 是一個列表，列表元素是我們執行命令的各個引數。
所以當我們執行單元測試命令的時候，會包含 test，所以資料庫的連結內容就會走我們這個邏輯。
在這部分，我們使用 ENGINE 來確定了後端資料庫的型別為 SQLite，然後透過 DATABASES["default"]["test"]["NAME"] 來指定我們的測試資料庫地址。
當我們執行單元測試的命令時，在系統根目錄下就會多出一個 test_db.sqlite3 的資料庫。
如果想獲取更多後端相關文章，可掃碼關注閱讀：
