Python 進階之源碼分析：如何將一個類方法變爲多個方法？

前一篇文章《Python 中如何實現參數化測試？》中，我提到了在 Python 中實現參數化測試的幾個庫，並留下一個問題：

它們是如何作到把一個方法變成多個方法，而且將每一個方法與相應的參數綁定起來的呢？

咱們再提煉一下，原問題等因而：在一個類中，如何使用裝飾器把一個類方法變成多個類方法（或者產生相似的效果）？

# 帶有一個方法的測試類
class TestClass:
    def test_func(self):
        pass

# 使用裝飾器，生成多個類方法
class TestClass:
    def test_func1(self):
        pass
    def test_func2(self):
        pass
    def test_func3(self):
        pass

Python 中裝飾器的本質就是移花接木，用一個新的方法來替代被裝飾的方法。在實現參數化的過程當中，咱們介紹過的幾個庫到底用了什麼手段/祕密武器呢？

一、ddt 如何實現參數化？

先回顧一下上篇文章中 ddt 庫的寫法：

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(self, first, second):
        pass

ddt 可提供 4 個裝飾器：1 個加在類上的 @ddt，還有 3 個加在類方法上的 @data、@unpack 和 @file_data（前文未說起）。

先看看加在類方法上的三個裝飾器的做用：

# ddt 版本（win）：1.2.1
def data(*values):
    global index_len
    index_len = len(str(len(values)))
    return idata(values)

def idata(iterable):
    def wrapper(func):
        setattr(func, DATA_ATTR, iterable)
        return func
    return wrapper

def unpack(func):
    setattr(func, UNPACK_ATTR, True)
    return func

def file_data(value):
    def wrapper(func):
        setattr(func, FILE_ATTR, value)
        return func
    return wrapper

它們的共同做用是在類方法上 setattr() 添加屬性。至於這些屬性在何時使用？下面看看加在類上的 @ddt 裝飾器源碼：

第一層 for 循環遍歷了全部的類方法，而後是 if/elif 兩條分支，分別對應 DATA_ATTR/FILE_ATTR，即對應參數的兩種來源：數據（@data）和文件（@file_data）。

elif 分支有解析文件的邏輯，以後跟處理數據類似，因此咱們把它略過，主要看前面的 if 分支。這部分的邏輯很清晰，主要完成的任務以下：

• 遍歷類方法的參數鍵值對
• 根據原方法及參數對，建立新的方法名
• 獲取原方法的文檔字符串
• 對元組和列表類型的參數做解包
• 在測試類上添加新的測試方法，並綁定參數與文檔字符串

分析源碼，能夠看出，@data、@unpack 和 @file_data 這三個裝飾器主要是設置屬性並傳參，而 @ddt 裝飾器纔是核心的處理邏輯。

這種將裝飾器分散（分別加在類與類方法上），再組合使用的方案，很不優雅。爲何就不能統一塊兒來使用呢？後面咱們會分析它的難言之隱，先按下不表，看看其它的實現方案是怎樣的？

二、parameterized 如何實現參數化？

先回顧一下上篇文章中 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)

它提供了一個裝飾器類 @parameterized，源碼以下（版本 0.7.1），主要作了一些初始的校驗和參數解析，並不是咱們關注的重點，略過。

咱們主要關注這個裝飾器類的 expand() 方法，它的文檔註釋中寫到：

A "brute force" method of parameterizing test cases. Creates new test cases and injects them into the namespace that the wrapped function is being defined in. Useful for parameterizing tests in subclasses of 'UnitTest', where Nose test generators don't work.

關鍵的兩個動做是：「creates new test cases（建立新的測試單元）」和「inject them into the namespace…（注入到原方法的命名空間）」。

關於第一點，它跟 ddt 是類似的，只是一些命名風格上的差別，以及參數的解析及綁定不一樣，不值得太關注。

最不一樣的則是，怎麼令新的測試方法生效？

parameterized 使用的是一種「注入」的方式：

inspect 是個功能強大的標準庫，在此用於獲取程序調用棧的信息。前三句代碼的目的是取出 f_locals，它的含義是「local namespace seen by this frame」，此處 f_locals 指的就是類的局部命名空間。

說到局部命名空間，你可能會想到 locals()，可是，咱們以前有文章提到過「locals() 與 globals() 的讀寫問題」，locals() 是可讀不可寫的，因此這段代碼才用了 f_locals。

三、pytest 如何實現參數化？

按慣例先看看上篇文章中的寫法：

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

首先看到「mark」，pytest 裏內置了一些標籤，例如 parametrize、timeout、skipif、xfail、tryfirst、trylast 等，還支持用戶自定義的標籤，能夠設置執行條件、分組篩選執行，以及修改原測試行爲等等。

用法也是很是簡單的，然而，其源碼可複雜多了。咱們這裏只關注 parametrize，先看看核心的一段代碼：

根據傳入的參數對，它複製了原測試方法的調用信息，存入待調用的列表裏。跟前面分析的兩個庫不一樣，它並無在此建立新的測試方法，而是複用了已有的方法。在 parametrize() 所屬的 Metafunc 類往上查找，能夠追蹤到 _calls 列表的使用位置：

最終是在 Function 類中執行：

好玩的是，在這裏咱們能夠看到幾行神註釋……

閱讀（粗淺涉獵） pytest 的源碼，真的是自討苦吃……不過，依稀大體能夠看出，它在實現參數化時，使用的是生成器的方案，遍歷一個參數則調用一次測試方法，而前面的 ddt 和 parameterized 則是一次性把全部參數解析完，生成 n 個新的測試方法，再交給測試框架去調度。

對比一下，前兩個庫的思路很清晰，並且因爲其設計單純是爲了實現參數化，不像 pytest 有什麼標記和過多的抽象設計，因此更易讀易懂。前兩個庫發揮了 Python 的動態特性，設置類屬性或者注入局部命名空間，而 pytest 倒像是從什麼靜態語言中借鑑的思路，略顯笨拙。

四、最後小結

回到標題中的問題「如何將一個方法變爲多個方法？」除了在參數化測試中，不知還有哪些場景會有此訴求？歡迎留言討論。

本文分析了三個測試庫的裝飾器實現思路，經過閱讀源碼，咱們能夠發現它們各有千秋，這個發現自己還挺有意思。在使用裝飾器時，表面看它們差別不大，可是真功夫的細節都隱藏在底下。

源碼分析的意義在於探究其因此然，在此次探究之旅中，讀者們可有什麼收穫啊？一塊兒來聊聊吧！（PS：在「Python貓」公衆號後臺發送「學習羣」，獲取加羣暗號。）