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
的資料庫,那就是我們執行單元測試之後沒有删除的測試資料庫。
當我們下次再執行這個或者其他單元測試的時候,可以發現執行的時間就變得很快了,而且在控制台會輸出這樣一條資訊:
意思就是使用已經存在的測試資料庫。
而不加 --keepdb 的時候,輸出的是:
表示的是正在建立新的測試資料庫。
注意: 雖然單元測試結束之後資料庫的結構還會保留,但是在單元測試中我們建立的資料還是會被删除。這個僅限于在單元測試中建立的資料,通過 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
參數這樣操作:
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
的資料庫。