深度學(xué)習(xí)是一門很難評估代碼正確性的學(xué)科。隨機(jī)初始化、龐大的數(shù)據(jù)集和權(quán)重的有限可解釋性意味著，要找到模型為什么不能訓(xùn)練的確切問題，大多數(shù)時候都需要反復(fù)試驗。在傳統(tǒng)的軟件開發(fā)中，自動化單元測試是確定代碼是否完成預(yù)期任務(wù)的面包和黃油。它幫助開發(fā)人員信任他們的代碼，并在引入更改時更加自信。一個破壞性的更改將會被單元測試檢測到。

[[338647]]

從GitHub上許多研究庫的情況來看，深度學(xué)習(xí)的實踐者們還不喜歡這種方法。從業(yè)者不知道他們的代碼是否正常工作，他們能接受嗎?通常，由于上述三個原因，學(xué)習(xí)系統(tǒng)的每個組件的預(yù)期行為并不容易定義。然而，我相信實踐者和研究人員應(yīng)該重新考慮他們對單元測試的厭惡，因為它可以幫助研究過程更加順利。你只需要學(xué)習(xí)如何信任你的代碼。

顯然，我不是第一個，也不是最后一個談?wù)撚糜谏疃葘W(xué)習(xí)的單元測試的人。如果你對這個話題感興趣，你可以看看這里：

• A Recipe for Training Neural Networks by Andrej Karpathy
• How to Unit Test Deep Learning by Sergios Karagiannakos

這篇文章的靈感來自于上面提到的，可能還有很多我現(xiàn)在想不起來的。為了在討論中增加一些內(nèi)容，我們將重點關(guān)注如何編寫可重用的單元測試，這樣就可以“不去自己重復(fù)自己“。

我們的例子將測試用PyTorch編寫的系統(tǒng)的組件，該系統(tǒng)在MNIST 上訓(xùn)練可變自動編碼器(VAE)。你可以在github.com/tilman151/unittest_dl上找到本文中的所有代碼。

什么是單元測試?

如果您熟悉單元測試，可以跳過此部分。對于其他人，我們將看到Python中的單元測試是什么樣子的。為了簡單起見，我們將使用內(nèi)置的包unittest，而不是其他花哨的包。

一般來說，單元測試的目的是檢查代碼是否正確地運行。通常(我也為此感到內(nèi)疚很長一段時間)，你會看到這樣的東西在一個文件的結(jié)尾：

if __name__ == 'main': 
    net = Network() 
    x = torch.randn(4, 1, 32, 32) 
    y = net(x) 
    print(y.shape) 

如果直接執(zhí)行該文件，則代碼片段將構(gòu)建一個網(wǎng)絡(luò)，執(zhí)行前向傳遞并打印輸出的形狀。這樣，我們就可以看到向前傳播是否會拋出錯誤，以及輸出的形狀是否可信。如果將代碼分發(fā)到不同的文件中，則必須手動運行每個文件，并檢查打印到控制臺的內(nèi)容。更糟糕的是，這個代碼片段有時會在運行后被刪除，當(dāng)有變化時被重寫。

原則上，這已經(jīng)是一個基本的單元測試。我們所要做的就是將它形式化一點，使它能夠輕松地自動運行。它看起來是這樣的：

import unittest 
 
class MyFirstTest(unittest.TestCase): 
    def test_shape(self): 
        net = Network() 
        x = torch.randn(4, 1, 32, 32) 
        y = net(x) 
        self.assertEqual(torch.Size((10,)), y.shape) 

unittest包的主要組件是類TestCase。單個單元測試是TestCase子類的成員函數(shù)。在我們的例子中，包將自動檢測類MyFirstTest并運行函數(shù)'test_shape。如果滿足assertEqual調(diào)用的條件，則測試成功。否則，或者如果它崩潰，測試將失敗。

我需要測試些什么?

現(xiàn)在我們已經(jīng)了解了單元測試是如何工作的，下一個問題是我們應(yīng)該測試什么。下面你可以看到我們的例子的代碼結(jié)構(gòu)：

|- src 
   |- dataset.py 
   |- model.py 
   |- trainer.py 
   |- run.py 

我們將測試每個文件中的功能除了run.py，因為它只是我們程序的入口點。

Dataset

我們在例子中使用的數(shù)據(jù)集是torchvisionMNIST類。因此，我們可以假設(shè)像加載圖像和訓(xùn)練/測試分割這樣的基本功能可以正常工作。然而，MNIST類為配置提供了充足的機(jī)會，因此我們應(yīng)該測試是否正確配置了所有內(nèi)容。dataset.py文件包含一個名為MyMNIST的類，它有兩個成員變量。成員train_data有torchvisionMNIST類的一個實例，該實例被配置為加載數(shù)據(jù)的訓(xùn)練部分，而test_data 中的實例加載測試部分。兩種方法都將每幅圖像每邊填充2個像素，并將像素值歸一化在[- 1,1]之間。此外，train_data 對每個圖像應(yīng)用隨機(jī)旋轉(zhuǎn)來增強(qiáng)數(shù)據(jù)。

數(shù)據(jù)的形狀

為了繼續(xù)使用上面的代碼片段，我們將首先測試數(shù)據(jù)集是否輸出了我們想要的形狀。圖像的填充意味著，它們現(xiàn)在的大小應(yīng)該是32x32像素。我們的測試看起來是這樣的：

def test_shape(self): 
    dataset = MyMNIST() 
    sample, _ = dataset.train_data[0] 
    self.assertEqual(torch.Shape((1, 32, 32)), sample.shape) 

現(xiàn)在我們可以確定我們的padding是我們想要的。這可能看起來很瑣碎，你們中的一些人可能會認(rèn)為我在測試這個方面很迂腐，但是我不知道我有多少次因為我搞不清楚填充函數(shù)是如何工作的而導(dǎo)致了形狀錯誤。像這樣的簡單測試編寫起來很快，并且可以為你以后省去許多麻煩。

數(shù)據(jù)的縮放

我們配置的下一件事是數(shù)據(jù)的縮放。在我們的例子中，這非常簡單。我們希望確保每個圖像的像素值在[- 1,1]之間。與之前的測試相反，我們將對數(shù)據(jù)集中的所有圖像進(jìn)行測試。通過這種方式，我們可以確定我們關(guān)于如何縮放數(shù)據(jù)的假設(shè)對于整個數(shù)據(jù)集是有效的。

def test_scaling(self): 
    dataset = MyMNIST() 
    for sample, _ in dataset.train_data: 
        self.assertGreaterEqual(1, sample.max()) 
        self.assertLessEqual(-1, sample.min()) 
        self.assertTrue(torch.any(sample < 0)) 
        self.assertTrue(torch.any(sample > 0)) 

如你所見，我們不僅要測試每個圖像的最大值和最小值是否在范圍內(nèi)。我們還通過斷言測試是否存在大于零和小于零的值，我們將值縮放到[0,1]。這個測試之所以有效，是因為我們可以假設(shè)MNIST中的每個圖像都覆蓋了整個范圍的值。對于更復(fù)雜的數(shù)據(jù)，比如自然圖像，我們需要一個更復(fù)雜的測試條件。如果你的縮放基于數(shù)據(jù)的統(tǒng)計信息，那么測試一下是否只使用訓(xùn)練部分來計算這些統(tǒng)計信息也是一個好主意。

數(shù)據(jù)增強(qiáng)

增加訓(xùn)練數(shù)據(jù)可以極大地幫助提高模型的性能，特別是在數(shù)據(jù)量有限的情況下。另一方面，我們不會增加我們的測試數(shù)據(jù)，因為我們想要保持我們的模型的評估確定性。這意味著，我們應(yīng)該測試我們的訓(xùn)練數(shù)據(jù)是否增加了，而我們的測試數(shù)據(jù)沒有。敏銳的讀者會在這一點上注意到一些重要的東西。到目前為止，我們的測試只涵蓋了訓(xùn)練數(shù)據(jù)。這是需要強(qiáng)調(diào)的一點：

始終在訓(xùn)練和測試數(shù)據(jù)上運行測試

僅僅因為你的代碼在數(shù)據(jù)的一個部分上工作，并不能保證在另一個部分上不存在未檢測到的bug。對于數(shù)據(jù)增強(qiáng)，我們甚至希望為每個部分?jǐn)嘌源a的不同行為。

對于我們的增強(qiáng)問題，一個簡單的測試現(xiàn)在是加載一個樣本兩次，然后檢查兩個版本是否相等。簡單的解決方案是為我們的每一個部分寫一個測試函數(shù)：

def test_augmentation_active_train_data(self): 
    dataset = MyMNIST() 
    are_same = [] 
    for i in range(len(dataset.train_data)): 
        sample_1, _ = dataset.train_data[i] 
        sample_2, _ = dataset.train_data[i] 
        are_same.append(0 == torch.sum(sample_1 - sample_2)) 
 
    self.assertTrue(not all(are_same)) 
 
def test_augmentation_inactive_test_data(self): 
    dataset = MyMNIST() 
    are_same = [] 
    for i in range(len(dataset.test_data)): 
        sample_1, _ = dataset.test_data[i] 
        sample_2, _ = dataset.test_data[i] 
        are_same.append(0 == torch.sum(sample_1 - sample_2)) 
 
    self.assertTrue(all(are_same)) 

這些函數(shù)測試我們想要測試的內(nèi)容，但是，正如你所看到的，它們幾乎就是重復(fù)的。這有兩個主要的缺點。首先，如果在測試中需要更改某些內(nèi)容，我們必須記住在兩個函數(shù)中都要更改。其次，如果我們想添加另一個部分，例如一個驗證部分，我們將不得不第三次復(fù)制測試。要解決這個問題，我們應(yīng)該將測試功能提取到一個單獨的函數(shù)中，然后由真正的測試函數(shù)調(diào)用兩次。重構(gòu)后的測試看起來像這樣：

def test_augmentation(self): 
    dataset = MyMNIST() 
    self._check_augmentation(dataset.train_data, active=True) 
    self._check_augmentation(dataset.test_data, active=False) 
 
def _check_augmentation(self, data, active): 
    are_same = [] 
    for i in range(len(data)): 
        sample_1, _ = data[i] 
        sample_2, _ = data[i] 
        are_same.append(0 == torch.sum(sample_1 - sample_2)) 
 
    if active: 
        self.assertTrue(not all(are_same)) 
    else: 
        self.assertTrue(all(are_same)) 

_check_augmentation函數(shù)斷言給定的數(shù)據(jù)集是否進(jìn)行了增強(qiáng)，并有效地刪除代碼中的重復(fù)。函數(shù)本身不會由unittest包自動運行，因為它不是以test_開頭的。因為我們的測試函數(shù)現(xiàn)在真的很短，我們把它們合并成一個組合函數(shù)。它們測試了增強(qiáng)是如何工作的這一單一的概念，因此應(yīng)該屬于相同的測試函數(shù)。但是，通過這個組合，我們引入了另一個問題。如果測試失敗了，現(xiàn)在很難直接看到哪一個部分失敗了。這個包只告訴我們組合函數(shù)的名稱。進(jìn)入subTest函數(shù)。TestCase類有一個成員函數(shù)subTest，它可以在一個測試函數(shù)中標(biāo)記不同的測試組件。這樣，包就可以準(zhǔn)確地告訴我們測試的哪一部分失敗了。最后的函數(shù)是這樣的：

def test_augmentation(self): 
    dataset = MyMNIST() 
    with self.subTest(split='train'): 
        self._check_augmentation(dataset.train_data, active=True) 
    with self.subTest(split='test'): 
        self._check_augmentation(dataset.test_data, active=False) 

現(xiàn)在我們有了一個無重復(fù)、精確定位、可重用的測試功能。我們在此所使用的核心原則可以應(yīng)用到我們在前面幾節(jié)中編寫的所有其他單元測試中。你可以在附帶的存儲庫中看到結(jié)果測試。

數(shù)據(jù)的加載

數(shù)據(jù)集的最后一種類型的單元測試與我們的例子并不完全相關(guān)，因為我們使用的是內(nèi)置數(shù)據(jù)集。無論如何我們都會把它包括進(jìn)來，因為它涵蓋了我們學(xué)習(xí)系統(tǒng)的一個重要部分。通常，你將在dataloader類中使用數(shù)據(jù)集，該類處理批處理并可以并行化加載。因此，測試你的數(shù)據(jù)集在單進(jìn)程和多進(jìn)程模式下是否與dataloader一起工作是一個好主意?？紤]到我們所學(xué)到的增強(qiáng)測試，測試函數(shù)如下所示：

def test_single_process_dataloader(self): 
    dataset = MyMNIST() 
    with self.subTest(split='train'): 
        self._check_dataloader(dataset.train_data, num_workers=0) 
    with self.subTest(split='test'): 
        self._check_dataloader(dataset.test_data, num_workers=0) 
 
def test_multi_process_dataloader(self): 
    dataset = MyMNIST() 
    with self.subTest(split='train'): 
        self._check_dataloader(dataset.train_data, num_workers=2) 
    with self.subTest(split='test'): 
        self._check_dataloader(dataset.test_data, num_workers=2) 
 
def _check_dataloader(self, data, num_workers): 
    loader = DataLoader(data, batch_size=4, num_workers=num_workers) 
    for _ in loader: 
        pass 

函數(shù)_check_dataloader不會對加載的數(shù)據(jù)進(jìn)行任何測試。我們只是想檢查加載過程是否沒有拋出錯誤。理論上，ni 也可以檢查諸如正確的批大小或填充的序列數(shù)據(jù)的不同長度。因為我們?yōu)閐ataloader使用了最基本的配置，所以可以省略這些檢查。

同樣，這個測試可能看起來瑣碎而沒有必要，但是讓我給你一個例子，在這個簡單的檢查中節(jié)省了我的時間。這個項目需要從pandas的dataframes中加載序列數(shù)據(jù)，并從這些datafames上的滑動窗口中構(gòu)造樣本。我們的數(shù)據(jù)集太大了，無法裝入內(nèi)存，所以我們必須按需加載數(shù)據(jù)模型，并從中剪切出所請求的序列。為了提高加載速度，我們決定用一個LRU cache來緩存一些數(shù)據(jù)文件。它在我們早期的單進(jìn)程實驗中如預(yù)期的那樣工作，因此我們決定將它包含在代碼庫中。結(jié)果是，這個緩存不能很好地用于多進(jìn)程，但是我們的單元測試提前發(fā)現(xiàn)了這個問題。在使用多進(jìn)程時，我們停用了緩存，避免了以后出現(xiàn)令人不快的意外。

最后要注意的

有些人可能已經(jīng)在我們的單元測試中看到了另一個重復(fù)的模式。每個測試對訓(xùn)練數(shù)據(jù)運行一次，對測試數(shù)據(jù)運行一次，產(chǎn)生相同的四行代碼：

with self.subTest(split='train'): 
    self._check_something(dataset.train_data) 
with self.subTest(split='test'): 
    self._check_dataloader(dataset.test_data) 

也完全有理由消除這種重復(fù)。不幸的是，這將涉及到創(chuàng)建一個高階函數(shù)，以函數(shù)_check_something作為參數(shù)。有時，例如對于增強(qiáng)測試，我們還需要向_check_something函數(shù)傳遞額外的參數(shù)。最后，所需的編程構(gòu)造將引入更多的復(fù)雜性，并模糊要測試的概念。一般的規(guī)則是，為了可讀性和可重用性，讓你的測試代碼盡可能在需要的范圍內(nèi)變復(fù)雜。

Model

模型可以說是學(xué)習(xí)系統(tǒng)的核心組件，通常需要是完全可配置的。這意味著，還有很多東西需要測試。幸運的是，PyTorch中用于神經(jīng)網(wǎng)絡(luò)模型的API非常簡潔，大多數(shù)實踐者都非常嚴(yán)格地使用它。這使得為模型編寫可重用的單元測試相當(dāng)容易。

我們的模型是一個簡單的VAE，由一個全連接的編碼器和解碼器組成。前向函數(shù)接受輸入圖像，對其進(jìn)行編碼，執(zhí)行重新參數(shù)化操作，然后將隱編碼解碼為圖像。雖然相對簡單，但這種變換可以演示幾個值得進(jìn)行單元測試的方面。

模型的輸出形狀

我們在本文開頭看到的第一段代碼是幾乎每個人都要做的測試。我們也已經(jīng)知道這個測試是如何寫成單元測試的。我們要做的唯一一件事就是添加要測試的正確形狀。對于一個自動編碼器，就簡單的判斷和輸入的形狀是否相同：

@torch.nograd() 
def test_shape(self): 
    net = model.MLPVAE(input_shape=(1, 32, 32), bottleneck_dim=16) 
    inputs = torch.randn(4, 1, 32, 32) 
    outputs = net(x) 
    self.assertEqual(inputs.shape, outputs.shape) 

同樣，這很簡單，但有助于找到一些最惱人的bug。例如，在將模型輸出從拉平的表示中reshape時忘記添加通道維度。

我們最后增加的測試是torch.nograd 。它告訴PyTorch這個函數(shù)不需要記錄梯度，并給我們一個小的加速。對于每個測試來說，它可能不是很多，但是你永遠(yuǎn)不知道需要編寫多少。同樣，這是另一個可引用的單元測試智慧：

讓你的測試更快。否則，沒有人會想要運行它們。

單元測試應(yīng)該在開發(fā)期間非常頻繁地運行。如果你的測試運行時間很長，那么你可以跳過它們。

模型的移動

在CPU上訓(xùn)練深度神經(jīng)網(wǎng)絡(luò)在大多數(shù)時候都非常慢。這就是為什么我們使用GPU來加速它。為此，我們所有的模型參數(shù)必須駐留在GPU上。因此，我們應(yīng)該斷言我們的模型可以在設(shè)備(CPU和多個GPU)之間正確地移動。

我們可以用一個常見的錯誤來說明我們的例子VAE中的問題。這里你可以看到bottleneck函數(shù)，執(zhí)行重新參數(shù)化的技巧：

def bottleneck(self, mu, log_sigma): 
    noise = torch.randn(mu.shape) 
    latent_code = log_sigma.exp() * noise + mu 
 
    return latent_code 

它取隱先驗的參數(shù)，從標(biāo)準(zhǔn)高斯分布中采樣一個噪聲張量，并使用參數(shù)對其進(jìn)行變換。這在CPU上運行沒有問題，但當(dāng)模型移動到GPU時失敗。問題是噪音張量是在CPU內(nèi)存中創(chuàng)建的，因為它是默認(rèn)的，并沒有移動到模型所在的設(shè)備上。一個簡單的錯誤和一個簡單的解決方案。我們用noise = torch.randn_like(mu)替換了這行有問題的代碼。這就產(chǎn)生了一個與張量mu相同形狀和在相同設(shè)備上的噪聲張量。

幫助我們盡早捕獲這些bug的測試：

@torch.no_grad() 
@unittest.skipUnless(torch.cuda.is_available(), 'No GPU was detected') 
def test_device_moving(self): 
    net = model.MLPVAE(input_shape=(1, 32, 32), bottleneck_dim=16) 
    net_on_gpu = net.to('cuda:0') 
    net_back_on_cpu = net_on_gpu.cpu() 
     
    inputs = torch.randn(4, 1, 32, 32) 
 
    torch.manual_seed(42) 
    outputs_cpu = net(inputs) 
    torch.manual_seed(42) 
    outputs_gpu = net_on_gpu(inputs.to('cuda:0')) 
    torch.manual_seed(42) 
    outputs_back_on_cpu = net_back_on_cpu(inputs) 
 
    self.assertAlmostEqual(0., torch.sum(outputs_cpu - outputs_gpu.cpu())) 
    self.assertAlmostEqual(0., torch.sum(outputs_cpu - outputs_back_on_cpu)) 

我們把網(wǎng)絡(luò)從一個CPU移動到另一個CPU，然后再移動回來，只是為了確保正確?，F(xiàn)在我們有了網(wǎng)絡(luò)的三份拷貝(移動網(wǎng)絡(luò)復(fù)制了它們)，并使用相同的輸入張量向前傳遞。如果網(wǎng)絡(luò)被正確移動，前向傳遞應(yīng)該在不拋出錯誤的情況下運行，并且每次產(chǎn)生相同的輸出。

為了運行這個測試，我們顯然需要一個GPU，但也許我們想在筆記本電腦上做一些快速測試。如果PyTorch沒有檢測到GPU，unittest.skipUnless 可以跳過測試。這樣可以避免將測試結(jié)果與失敗的測試混淆。

你還可以看到，我們在每次通過之前固定了torch的隨機(jī)種子。我們必須這樣做，因為VAEs是非確定性的，否則我們會得到不同的結(jié)果。這說明了深度學(xué)習(xí)代碼單元測試的另一個重要概念：

在測試中控制隨機(jī)性。

如果你不能確保你的模型能到邊界情況，你如何測試你的模型的一個罕見邊界條件?如何確保模型的輸出是確定性的?你如何知道一個失敗的測試是由于隨機(jī)的偶然還是由于你引入的bug ?通過手動設(shè)置深度學(xué)習(xí)框架的種子，可以消除函數(shù)中的隨機(jī)性。此外，還應(yīng)該將CuDNN設(shè)置為確定性模式。這主要影響卷積，但無論如何是一個好主意。

注意確定正在使用的所有框架的種子。Numpy和內(nèi)置的Python隨機(jī)數(shù)生成器有它們自己的種子，必須分別設(shè)置。有一個這樣的函數(shù)是很有用的：

def make_deterministic(seed=42): 
    # PyTorch 
    torch.manual_seed(seed) 
    if torch.cuda.is_available(): 
        torch.backends.cudnn.deterministic = True 
        torch.backends.cudnn.benchmark = False 
     
    # Numpy 
    np.random.seed(seed) 
     
    # Built-in Python 
    random.seed(seed) 

模型到采樣獨立性

在99。99%的情況下，你都想用隨機(jī)梯度下降的方式來訓(xùn)練你的模型。你給你的模型一個minibatch的樣本，并計算他們的平均損失。批量處理訓(xùn)練樣本假設(shè)你的模型可以處理每個樣本，也就是你可以獨立的把樣本喂給模型。換句話說，你的batch中的樣本在你的模型處理時不會相互影響。這個假設(shè)是很脆弱的，如果在一個錯誤的張量維度上進(jìn)行錯誤的reshape或aggregation，就會打破這個假設(shè)。

下面的測試通過執(zhí)行與輸入相關(guān)的前向和后向傳遞來檢查樣本的獨立性。在對這個batch做平均損失之前，我們把損失乘以零。如果我們的模型保持樣本獨立性，這將導(dǎo)致一個零梯度。唯一的事情，我們必須斷言，如果只有masked的樣本梯度是零：

def test_batch_independence(self): 
    inputs = torch.randn(4, 1, 32, 32) 
    inputs.requires_grad = True 
    net = model.MLPVAE(input_shape=(1, 32, 32), bottleneck_dim=16) 
 
    # Compute forward pass in eval mode to deactivate batch norm 
    net.eval() 
    outputs = net(inputs) 
    net.train() 
 
    # Mask loss for certain samples in batch 
    batch_size = inputs[0].shape[0] 
    mask_idx = torch.randint(0, batch_size, ()) 
    mask = torch.ones_like(outputs) 
    mask[mask_idx] = 0 
    outputs = outputs * mask 
 
    # Compute backward pass 
    loss = outputs.mean() 
    loss.backward() 
 
    # Check if gradient exists and is zero for masked samples 
    for i, grad in enumerate(inputs.grad): 
        if i == mask_idx: 
            self.assertTrue(torch.all(grad == 0).item()) 
        else: 
            self.assertTrue(not torch.all(grad == 0)) 

如果你準(zhǔn)確地閱讀了代碼片段，你會注意到我們將模型設(shè)置為evaluation模式。這是因為batch normalization違反了我們上面的假設(shè)。進(jìn)程均值和標(biāo)準(zhǔn)差的處理交叉污染了我們batch中的樣本，所以我們通過evaluation模式停止了對樣本的更新。我們可以這樣做，因為我們的模型在訓(xùn)練和評估模式中表現(xiàn)相同。如果你的模型不是這樣的，你將不得不找到另一種方法來禁用它進(jìn)行測試。一個選項是用instance normalization臨時替換它。

上面的測試函數(shù)非常通用，可以按原樣復(fù)制。例外情況是，如果你的模型接受多個輸入。處理這個問題的附加代碼是必要的。

模型的參數(shù)更新

下一個測試也與梯度有關(guān)。當(dāng)你的網(wǎng)絡(luò)架構(gòu)變得更加復(fù)雜時，比如初始化，很容易構(gòu)建死子圖。死子圖是網(wǎng)絡(luò)中包含可學(xué)習(xí)參數(shù)的一部分，前向傳遞、后向傳遞或兩者都不使用。這就像在構(gòu)造函數(shù)中構(gòu)建一個網(wǎng)絡(luò)層，然后忘記在forward函數(shù)中應(yīng)用它一樣簡單。

找到這些死子圖可以通過運行優(yōu)化步驟并檢查梯度你的網(wǎng)絡(luò)參數(shù)：

def test_all_parameters_updated(self): 
    net = model.MLPVAE(input_shape=(1, 32, 32), bottleneck_dim=16) 
    optim = torch.optim.SGD(net.parameters(), lr=0.1) 
 
    outputs = net(torch.randn(4, 1, 32, 32)) 
    loss = outputs.mean() 
    loss.backward() 
    optim.step() 
 
    for param_name, param in self.net.named_parameters(): 
        if param.requires_grad: 
            with self.subTest(name=param_name): 
                self.assertIsNotNone(param.grad) 
                self.assertNotEqual(0., torch.sum(param.grad ** 2)) 

參數(shù)函數(shù)返回的模型的所有參數(shù)在優(yōu)化步驟后都應(yīng)該有一個梯度張量。此外，對于我們所使用的損失，它不應(yīng)該是零。測試假設(shè)模型中的所有參數(shù)都需要梯度。即使是那些不應(yīng)該被更新的參數(shù)也會首先檢查requires_grad標(biāo)志。如果任何參數(shù)在測試中失敗，子測試的名稱將提示你在哪里查找。

提高重用性

現(xiàn)在我們已經(jīng)寫出了模型的所有測試，我們可以將它們作為一個整體進(jìn)行分析。我們將注意到這些測試有兩個共同點。所有測試都從創(chuàng)建模型和定義示例輸入批處理開始。與以往一樣，這種冗余級別有可能導(dǎo)致拼寫錯誤和不一致。此外，你不希望在更改模型的構(gòu)造函數(shù)時分別更新每個測試。

幸運的是，unittest為我們提供了一個簡單的解決方案，即setUp函數(shù)。這個函數(shù)在執(zhí)行TestCase中的每個測試函數(shù)之前被調(diào)用，通常為空。通過在setUp中將模型和輸入定義為TestCase的成員變量，我們可以在一個地方初始化測試的組件。

class TestVAE(unittest.TestCase): 
    def setUp(self): 
        self.net = model.MLPVAE(input_shape=(1, 32, 32), bottleneck_dim=16) 
        self.test_input = torch.random(4, 1, 32, 32) 
 
    ... # Test functions 

現(xiàn)在我們用各自的成員變量替換出現(xiàn)的net和inputs，這樣就完成了。如果你想更進(jìn)一步，對所有測試使用相同的模型實例，您可以使用setUpClass。這個函數(shù)在構(gòu)造TestCase時被調(diào)用一次。如果構(gòu)建速度很慢，并且你不想多次進(jìn)行構(gòu)建，那么這是非常有用的。

在這一點上，我們有一個整潔的系統(tǒng)來測試我們的VAE模型。我們可以輕松地添加測試，并確保每次都測試模型的相同版本。但是如果你想引入一種新的卷積層，會發(fā)生什么呢?它將在相同的數(shù)據(jù)上運行，也應(yīng)該具有相同的行為，因此將應(yīng)用相同的測試。

僅僅復(fù)制整個TestCase 顯然不是首選的解決方案，但是通過使用setUp，我們已經(jīng)在正確的軌道上了。我們將所有測試函數(shù)轉(zhuǎn)移到一個基類中，而將setUp保留為一個抽象函數(shù)。

class AbstractTestVAE(unittest.TestCase): 
    def setUp(self): 
        raise NotImplementedError 
 
    ... # Test functions 

你的IDE會提示類沒有成員變量net 和test_inputs，但是Python并不關(guān)心。只要子類添加了它們，它就可以工作。對于我們想要測試的每個模型，我們創(chuàng)建這個抽象類的一個子類，并在其中實現(xiàn)setUp。為多個模型或同一個模型的多個配置創(chuàng)建TestCases 就像：

class TestCNNVAE(AbstractTestVAE): 
    def setUp(self): 
        self.test_inputs = torch.randn(4, 1, 32, 32) 
        self.net = model.CNNVAE(input_shape=(1, 32, 32), bottleneck_dim=16) 
 
class TestMLPVAE(AbstractTestVAE): 
    def setUp(self): 
        self.test_inputs = torch.randn(4, 1, 32, 32) 
        self.net = model.MLPVAE(input_shape=(1, 32, 32), bottleneck_dim=16) 

只剩下一個問題了。unittest包發(fā)現(xiàn)并運行unittest.TestCase的所有子元素。因為這包括不能實例化的抽象基類，所以我們總是會有一個失敗的測試。

解決方案是由一個流行的設(shè)計模式提出的。通過刪除TestCase作為AbstractTestVAE的父類，它就不再被發(fā)現(xiàn)了。相反，我們讓我們的具體測試有兩個父類， TestCase和AbstractTestVAE。抽象類和具體類之間的關(guān)系不再是父類和子類之間的關(guān)系。相反，具體類使用抽象類提供的共享功能。這個模式稱為MixIn。

class AbstractTestVAE: 
    ... 
 
class TestCNNVAE(unittest.TestCase, AbstractTestVAE): 
    ... 
 
class TestMLPVAE(unittest.TestCase, AbstractTestVAE): 
    ... 

父類的順序很重要，因為方法查找是從左到右進(jìn)行的。這意味著TestCase將覆蓋AbstractTestVAE的共享方法。在我們的例子中，這不是一個問題，但無論如何知道都是好的。

Trainer

我們的學(xué)習(xí)系統(tǒng)的最后一部分是trainer類。它將你所有的組件(數(shù)據(jù)集、優(yōu)化器和模型)放在一起，并使用它們來訓(xùn)練模型。此外，它還實現(xiàn)了一個評估函數(shù)，輸出測試數(shù)據(jù)的平均損失。在訓(xùn)練時，所有的損失和指標(biāo)都被寫入一個TensorBoard event文件中以便可視化。

在這一部分中，編寫可重用測試是最困難的，因為它允許最大程度的自由實現(xiàn)。有些人只在腳本文件中使用簡單的代碼進(jìn)行訓(xùn)練，有些人將其封裝在函數(shù)中，還有一些人試圖保持更面向?qū)ο蟮娘L(fēng)格。我不會判斷你喜歡哪種方式。我唯一要說的是，在我的經(jīng)驗中，整潔封裝的trainer類使單元測試變得最舒適。

然而，我們會發(fā)現(xiàn)我們之前學(xué)過的一些原則在這里也適用。

trainer的損失

大多數(shù)時候，你只需要從torch上選擇一個預(yù)先實現(xiàn)的損失函數(shù)就可以了。但話說回來，你所選擇的損失函數(shù)可能無法實現(xiàn)。這種情況可能是由于實現(xiàn)相對簡單，函數(shù)太小眾或者太新。無論如何，如果你自己實現(xiàn)了它，你也應(yīng)該測試它。

我們的例子使用Kulback-Leibler (KL)散度作為整體損失函數(shù)的一部分，這在PyTorch中是不存在的(現(xiàn)在的版本里有了)。我們的實現(xiàn)是這樣的：

def _kl_divergence(log_sigma, mu): 
    return 0.5 * torch.sum((2 * log_sigma).exp() + mu ** 2 - 1 - 2 * log_sigma) 

函數(shù)取多變量高斯分布的標(biāo)準(zhǔn)偏差和平均值的對數(shù)，并計算在封閉形式中的標(biāo)準(zhǔn)高斯分布的KL散度。

檢查這種損失的一種方法是手工計算，然后硬編碼以便比較。更好的方法是在另一個包中找到一個參考實現(xiàn)，并根據(jù)它的輸出檢查代碼。幸運的是，scipy包有一個離散KL散度的實現(xiàn)，我們可以使用：

@torch.no_grad() 
def test_kl_divergence(self): 
    mu = np.random.randn(10) * 0.25  # means around 0. 
    sigma = np.random.randn(10) * 0.1 + 1.  # stds around 1. 
    standard_normal_samples = np.random.randn(100000, 10) 
    transformed_normal_sample = standard_normal_samples * sigma + mu 
 
    bins = 1000 
    bin_range = [-2, 2] 
    expected_kl_div = 0 
    for i in range(10): 
        standard_normal_dist, _ = np.histogram(standard_normal_samples[:, i], bins, bin_range) 
        transformed_normal_dist, _ = np.histogram(transformed_normal_sample[:, i], bins, bin_range) 
        expected_kl_div += scipy.stats.entropy(transformed_normal_dist, standard_normal_dist) 
 
    actual_kl_div = self.vae_trainer._kl_divergence(torch.tensor(sigma).log(), torch.tensor(mu)) 
 
    self.assertAlmostEqual(expected_kl_div, actual_kl_div.numpy(), delta=0.05) 

我們首先從標(biāo)準(zhǔn)高斯函數(shù)和一個不同均值和標(biāo)準(zhǔn)差的高斯函數(shù)中抽取一個足夠大的樣本。然后我們用np.histogram函數(shù)，得到基本pdf的離散逼近。有了這些，我們就可以用scipy.stats.entropy得到一個KL散度來比較。我們使用一個相對較大的delta來進(jìn)行比較，因為scipy.stats.entropy只是一個近似值。

你可能已經(jīng)注意到，我們沒有創(chuàng)建Trainer對象，而是使用TestCase的成員。我們在這里使用了與模型測試相同的技巧，并在setUp函數(shù)中創(chuàng)建了它。我們還固定了PyTorch和NumPy的種子。因為我們這里不需要任何梯度，所以我們用@torch.no_grad來裝飾函數(shù)。

trainer的日志記錄

我們使用TensorBoard來記錄我們的訓(xùn)練過程的損失和度量。為此，我們希望確保按預(yù)期寫入所有日志。一種方法是在訓(xùn)練后打開event文件，查找正確的event。同樣，這也是一個有效的選項，但我們將以另一種方式來看看unittest包的一個有趣功能：mock。

mock允許你用一個監(jiān)視其自身是如何調(diào)用的函數(shù)來打包一個函數(shù)或?qū)ο?。我們將替換summary writer的add_scalar 函數(shù)，并確保以這種方式記錄我們關(guān)心的所有損失和指標(biāo)。

def test_logging(self): 
    with mock.patch.object(self.vae_trainer.summary, 'add_scalar') as add_scalar_mock: 
        self.vae_trainer.train(1) 
 
    expected_calls = [mock.call('train/recon_loss', mock.ANY, 0), 
                      mock.call('train/kl_div_loss', mock.ANY, 0), 
                      mock.call('train/loss', mock.ANY, 0), 
                      mock.call('test/loss', mock.ANY, 0)] 
    add_scalar_mock.assert_has_calls(expected_calls) 

assert_has_calls 函數(shù)匹配預(yù)期調(diào)用列表和實際記錄的調(diào)用。mock.ANY 表示我們不關(guān)心記錄的標(biāo)量的值，因為無論如何我們都不知道它。

因為我們不需要對整個數(shù)據(jù)集執(zhí)行完一個epoch，所以我們在setUp 中將訓(xùn)練數(shù)據(jù)配置為只有一個batch。這樣，我們可以顯著地加快我們的測試速度。

trainer的擬合

最后一個問題也是最難回答的。我的訓(xùn)練最終會收斂嗎?要確切地回答這個問題，我們需要用我們所有的數(shù)據(jù)進(jìn)行一次全面的訓(xùn)練并對其打分。

由于這非常耗時，我們將使用一種更快的方法。我們將看看我們的訓(xùn)練是否能使模型對單個batch的數(shù)據(jù)進(jìn)行過擬合。測試函數(shù)相當(dāng)簡單：

def test_overfit_on_one_batch(self): 
    self.vae_trainer.train(500) 
    self.assertGreaterEqual(30, self.vae_trainer.eval()) 

如前一節(jié)所述，setUp函數(shù)創(chuàng)建一個只包含一個batch的數(shù)據(jù)集的trainer。此外，我們也使用訓(xùn)練數(shù)據(jù)作為測試數(shù)據(jù)。通過這種方式，我們可以從 eval函數(shù)中獲得訓(xùn)練batch的損失，并將其與我們預(yù)期的損失進(jìn)行比較。

對于一個分類問題，當(dāng)我們完全過擬合時，我們期望損失為零。“VAE”的問題是，它是一個非確定性的生成模型，零損失是不現(xiàn)實的。這就是為什么我們預(yù)期的損失是30，這等于每像素的誤差為0.04。

這是迄今為止運行時間最長的測試，它可以運行500 epochs。最后，在我的筆記本電腦上用1.5分鐘左右就可以了，這仍然是合理的。為了在不降低對沒有GPU的機(jī)器的支持的情況下進(jìn)一步加速，我們可以簡單地在setUp中添加這一行：

device = 'cuda:0' if torch.cuda.is_available() else 'cpu' 

這樣一來，如果我們有GPU，我們就可以利用它，如果沒有，就利用CPU進(jìn)行訓(xùn)練。

最后要注意的

在我們進(jìn)行日志記錄時，你可能會注意到，針對trainer的單元測試往往會使你的文件夾充滿event文件。為了避免這種情況，我們使用tempfile 包為trainer創(chuàng)建一個臨時日志目錄。測試結(jié)束后，我們只需要再次刪除它和它的內(nèi)容。為此，我們使用了孿生函數(shù)setUp,和tearDown。在每個測試函數(shù)后調(diào)用此函數(shù)，清理過程簡單如下：

def tearDown(self): 
    shutil.rmtree(self.log_dir) 

總結(jié)

我們看完了這篇文章。讓我們評估一下我們從整個磨難中得到了什么。

我們?yōu)槲覀兊男±泳帉懙臏y試套件包含58個單元測試，整個運行大約需要3.5分鐘。對于這58個測試，我們只編寫了20個函數(shù)。所有測試都可以確定地、獨立地運行。如果有GPU，我們可以運行額外的測試。大多數(shù)測試，例如數(shù)據(jù)集和模型測試，可以在其他項目中輕松重用。我們可以通過使用：

• 子測試為我們的數(shù)據(jù)集的多種配置運行一個測試
• setUp和tearDown函數(shù)一致地初始化和清理我們的測試
• 抽象測試類來測試VAE的不同實現(xiàn)
• torch.no_grad裝飾器在可能的情況下禁用梯度計算
• mock模塊檢查函數(shù)是否被正確調(diào)用

最后，我希望我能夠說服至少有人在他們的深度學(xué)習(xí)項目中使用單元測試。本文的配套git倉庫可以作為起點。