[[285295]]

之前，我曾轉(zhuǎn)過一個單元測試框架系列的文章，里面介紹了 unittest、nose/nose2 與 pytest 這三個最受人歡迎的 Python 測試框架。

本文想針對測試中一種很常見的測試場景，即參數(shù)化測試，繼續(xù)聊聊關于測試的話題，并嘗試將這幾個測試框架串聯(lián)起來，做一個橫向的比對，加深理解。

1、什么是參數(shù)化測試？

對于普通測試來說，一個測試方法只需要運行一遍，而參數(shù)化測試對于一個測試方法，可能需要傳入一系列參數(shù)，然后進行多次測試。

比如，我們要測試某個系統(tǒng)的登錄功能，就可能要分別傳入不同的用戶名與密碼，進行測試：使用包含非法字符的用戶名、使用未注冊的用戶名、使用超長的用戶名、使用錯誤的密碼、使用合理的數(shù)據(jù)等等。

參數(shù)化測試是一種“數(shù)據(jù)驅(qū)動測試”（Data-Driven Test），在同一個方法上測試不同的參數(shù)，以覆蓋所有可能的預期分支的結(jié)果。它的測試數(shù)據(jù)可以與測試行為分離，被放入文件、數(shù)據(jù)庫或者外部介質(zhì)中，再由測試程序讀取。

2、參數(shù)化測試的實現(xiàn)思路？

通常而言，一個測試方法就是一個最小的測試單元，其功能應該盡量地原子化和單一化。

先來看看兩種實現(xiàn)參數(shù)化測試的思路：一種是寫一個測試方法，在其內(nèi)部對所有測試參數(shù)進行遍歷；另一種是在測試方法之外寫遍歷參數(shù)的邏輯，然后依次調(diào)用該測試方法。

這兩種思路都能達到測試目的，在簡單業(yè)務中，沒有毛病。然而，實際上它們都只有一個測試單元，在統(tǒng)計測試用例數(shù)情況，或者生成測試報告的時候，并不樂觀?？蓴U展性也是個問題。

那么，現(xiàn)有的測試框架是如何解決這個問題的呢？

它們都借助了裝飾器，主要的思路是：利用原測試方法（例如 test()），來生成多個新的測試方法（例如 test1()、test2()……），并將參數(shù)依次賦值給它們。

由于測試框架們通常把一個測試單元統(tǒng)計為一個“test”，所以這種“由一生多”的思路相比前面的兩種思路，在統(tǒng)計測試結(jié)果時，就具有很大的優(yōu)勢。

3、參數(shù)化測試的使用方法？

Python 標準庫中的unittest 自身不支持參數(shù)化測試，為了解決這個問題，有人專門開發(fā)了兩個庫：一個是ddt ，一個是parameterized 。

ddt 正好是“Data-Driven Tests”（數(shù)據(jù)驅(qū)動測試）的縮寫。典型用法： 

import unittest  
from ddt import ddt,data,unpack  
@ddt  
class MyTest(unittest.TestCase):  
    @data((3, 1), (-1, 0), (1.2, 1.0))  
    @unpack  
    def test_values(self, first, second):  
        self.assertTrue(first > second)  
unittest.main(verbosity=2) 

運行的結(jié)果如下： 

test_values_1__3__1_ (__main__.MyTest) ... ok  
test_values_2___1__0_ (__main__.MyTest) ... FAIL  
test_values_3__1_2__1_0_ (__main__.MyTest) ... ok  
==================================================  
FAIL: test_values_2___1__0_ (__main__.MyTest)  
--------------------------------------------------  
Traceback (most recent call last):  
  File "C:\Python36\lib\site-packages\ddt.py", line 145, in wrapper  
    return func(self, *args, **kwargs)  
  File "C:/Users/pythoncat/PycharmProjects/study/testparam.py", line 9, in test_values  
    self.assertTrue(first > second)  
AssertionError: False is not true  
----------------------------------------------  
Ran 3 tests in 0.001s  
FAILED (failures=1) 

結(jié)果顯示有 3 個 tests，并詳細展示了運行狀態(tài)以及斷言失敗的信息。

需要注意的是，這 3 個 test 分別有一個名字，名字中還攜帶了其參數(shù)的信息，而原來的 test_values 方法則不見了，已經(jīng)被一拆為三。

在上述例子中，ddt 庫使用了三個裝飾器（@ddt、@data、@unpack），實在是很丑陋。下面看看相對更好用的 parameterized 庫： 

import unittest  
from parameterized import parameterized  
class MyTest(unittest.TestCase):  
    @parameterized.expand([(3,1), (-1,0), (1.5,1.0)])  
    def test_values(self, first, second):  
        self.assertTrue(first > second)  
unittest.main(verbosity=2)  

測試結(jié)果如下： 

test_values_0 (__main__.MyTest) ... ok  
test_values_1 (__main__.MyTest) ... FAIL  
test_values_2 (__main__.MyTest) ... ok  
=========================================  
FAIL: test_values_1 (__main__.MyTest)  
-----------------------------------------  
Traceback (most recent call last):  
  File "C:\Python36\lib\site-packages\parameterized\parameterized.py", line 518, in standalone_func  
    return func(*(a + p.args), **p.kwargs)  
  File "C:/Users/pythoncat/PycharmProjects/study/testparam.py", line 7, in test_values  
    self.assertTrue(first > second)  
AssertionError: False is not true  
----------------------------------------  
Ran 3 tests in 0.000s  
FAILED (failures=1) 

這個庫只用了一個裝飾器 @parameterized.expand，寫法上可就清爽多了。

同樣提醒下，原來的測試方法已經(jīng)消失了，取而代之的是三個新的測試方法，只是新方法的命名規(guī)則與 ddt 的例子不同罷了。

介紹完 unittest，接著看已經(jīng)死翹翹了的nose 以及新生的nose2 。nose 系框架是帶了插件（plugins）的 unittest，以上的用法是相通的。

另外，nose2 中還提供了自帶的參數(shù)化實現(xiàn)： 

import unittest  
from nose2.tools import params  
@params(1, 2, 3)  
def test_nums(num):  
    assert num < 4  
class Test(unittest.TestCase):  
    @params((1, 2), (2, 3), (4, 5))  
    def test_less_than(self, a, b):  
    assert a < b 

最后，再來看下 pytest 框架，它這樣實現(xiàn)參數(shù)化測試： 

import pytest  
@pytest.mark.parametrize("first,second", [(3,1), (-1,0), (1.5,1.0)])  
def test_values(first, second):  
    assert(first > second) 

測試結(jié)果如下： 

==================== test session starts ====================  
platform win32 -- Python 3.6.1, pytest-5.3.1, py-1.8.0, pluggy-0.13.1  
rootdir: C:\Users\pythoncat\PycharmProjects\study collected 3 items  
testparam.py .F  
testparam.py:3 (test_values[-1-0])  
first = -1, second = 0  
    @pytest.mark.parametrize("first,second", [(3,1), (-1,0), (1.5,1.0)])  
    def test_values(first, second):  
>       assert(first > second)  
E       assert -1 > 0  
testparam.py:6: AssertionError  
.                                                         [100%]  
========================= FAILURES ==========================  
_________________________ test_values[-1-0] _________________________  
first = -1, second = 0   
    @pytest.mark.parametrize("first,second", [(3,1), (-1,0), (1.5,1.0)])  
    def test_values(first, second):  
>       assert(first > second)  
E       assert -1 > 0  
testparam.py:6: AssertionError  
===================== 1 failed, 2 passed in 0.08s =====================  
Process finished with exit code 0 

依然要提醒大伙注意，pytest 也做到了由一變?nèi)?，然而我們卻看不到有新命名的方法的信息。這是否意味著它并沒有產(chǎn)生新的測試方法呢？或者僅僅是把新方法的信息隱藏起來了？

4、最后小結(jié)

上文中介紹了參數(shù)化測試的概念、實現(xiàn)思路，以及在三個主流的 Python 測試框架中的使用方法。我只用了最簡單的例子，為的是快速科普（言多必失）。

但是，這個話題其實還沒有結(jié)束。對于我們提到的幾個能實現(xiàn)參數(shù)化的庫，拋去寫法上大同小異的區(qū)別，它們在具體代碼層面上，又會有什么樣的差異呢？

具體來說，它們是如何做到把一個方法變成多個方法，并且將每個方法與相應的參數(shù)綁定起來的呢？在實現(xiàn)中，需要解決哪些棘手的問題？

在分析一些源碼的時候，我發(fā)現(xiàn)這個話題還挺有意思，所以準備另外寫一篇文章。那么，本文就到此為止了，謝謝閱讀。