單元測試之道

時間 2019-11-19

標籤單元測試之道简体版

原文原文鏈接

標籤：單元測試前言系列html

1. 前言

在一個項目當中，開發者經常要作大量的測試工做，如單元測試，集成測試，迴歸測試，壓力測試 .etc。固然，依據項目狀況大小和開發者人員水平不一樣，測試涵蓋的方面天然也是不同的。一些測試須要相應的硬件和人力資源，一些須要專門的測試小組，另外一些須要提供細緻處理和長時間不間斷運行的環境。程序員

可是今天說的單元測試則不一樣，它是一種看起來十分廉價和基礎的技術。它由後臺程序開發人員建立運行，單機運行，刨除代碼量之外，對一個完整的項目開發成本而言，所需的人力物力都是相對較小的。而長久以來的事實也已經證實，單元測試對於代碼規範性和高效性，以及項目Bug的捕獲和解決都有很大的幫助。大多數開發者其實瞭解這樣的事實，只是由於一些內在和外在的因素（一般是不重視，時間緊和嫌麻煩），每每不肯意進行這些測試，或者只在項目快要結束時纔想起來，只是已經爲時已晚。算法

因此諸如TDD（測試驅動開發）的項目開發方式，都提倡一個核心道理：單元測試應該早作，多作，這樣既避免了過分設計，對有效編碼，項目依賴解耦也有好處。並且咱們始終要明確，單元測試的第一受益者，永遠是程序員。接下來，就讓咱們來看看單元測試的一些相關狀況，以後再在.NET項目中實際運行單元測試吧。編程

2. 單元測試總覽

讓咱們根據3W+1H原則，先對單元測試有個系統性認識吧後端

2.1 什麼是單元測試（WHAT）

當咱們在談論單元測試的時候，咱們在談些什麼。——村上春樹api

按照維基百科上的說法，單元測試（Unit Testing）又稱爲模塊測試, 是針對程序模塊（軟件設計的最小單位）來進行正確性檢驗的測試工做。程序單元是應用的最小可測試部件。在面向對象編程中，最小單元就是方法，包括基類、抽象類、或者派生類（子類）中的方法。按照通俗的理解，一個單元測試判斷某個特定場條件下某個特定方法的行爲，如斐波那契數列算法，冒泡排序算法。前後端分離

單元測試將被測試應用程序細分爲一個個足夠小的基本單元，各個單元間相互獨立，互不影響。開發者能經過單元測試，證實被測試函數的行爲確實和開發者指望的一致。爲了知足這個最基本的願望，書寫單元測試前，咱們不用考慮太多關於性能上的事情，這是以後優化重構該作的事情。函數

2.2 爲何使用單元測試（WHY）

愛作單元測試的程序員，代碼都不會太差。——古龍工具

上文說到，經常因爲項目工期緊張，抑或是程序員自身緣由的問題，團隊每每在項目接近完成時才進行測試。這實際上是很是不提倡的一種作法。就好像咱們僱了一批人給咱們造房子，從地基開始，造到十幾層了，才用懸垂線來測房子傾斜度同樣不靠譜（假如這個比喻靠譜的話）。到時候高層依賴底層，高層調試時發現bug，又得讓咱們返回底層查找問題，即使修改以後仍然經過了，可是想必不少朋友也遇到過項目代碼覆蓋度比較高，一改基礎方法影響一大片的問題吧。性能

因此當咱們從一開始就進行正確的單元測試時，這些問題都是能夠解決的。如下羅列出了幾個簡單的做用，以供參考

2.2.1 快速定位

單元測試最基本的一個功能，就是快速定位代碼中的錯誤。從項目一開始，開發者便對全部的單元模塊進行測試的話，，除了能儘早發現問題，另外一方面對咱們項目的持續開發無疑也是提供了極大的保障。

2.2.2 文檔記錄

當咱們設計出一個良好的單元測試環境，咱們勢必會對全部的基本單元進行測試，這時候，單元測試相對於爲咱們編寫了一份api文檔，咱們隨時能夠查閱方法相關參數和返回值，以及運行狀況。

2.2.3 適應變動

單元測試容許程序員在以後的開發工做中重構代碼，而且確保單元依然工做正確。這個過程就是爲全部函數和方法編寫單元測試。在連續的單元測試環境中，只要設計出了良好的驗證手段，單元測試能夠延續用於準確反映當任何變動發生時可執行程序和代碼的表現，幫助開發者優化代碼邏輯和代碼結構。

2.2.4 規範設計

進行單元測試時，開發者其實站在了一個觀察調試的上帝角度。不管是開發先於測試，仍是測試先於開發，單元測試均可以幫助咱們將模塊設計成易測試，易調試，易重構。在這個過程當中，開發者的編碼能力和對業務的理解能力也將獲得鍛鍊

2.3 何時決定進行單元測試（WHEN）

早。——魯迅

單元測試這東西，就跟戒菸同樣。每一個菸民都知道吸菸的壞處（bug），一開始吸菸的時候也會有人提醒你趕快戒菸吧，可是你每每並不在乎，等到年限一長（項目開發迭代屢次），由於吸菸身體出現的問題愈來愈嚴重，你可能在這以前作過幾回體檢（集成測試），可是依然於事無補了，等這時候再懷念當初戒菸，乃至不抽菸的好，也是爲時已晚。因此單元測試，就該在項目一開始的時候進行測試，在你起了「編寫單元測試太麻煩了，仍是算了」的念頭的時候就該開始。博主代碼水平有限，無止盡的debug和bug提交已經耗費了我很大的精力，因此這才下定決心開始單元測試之旅。

確實不能否認，剛開始就編寫單元測試經常要多花費幾倍的代碼量，可是隨着項目進行，當你把基礎方法都測試過之後，高層功能須要的代碼量反而會大大減小。這時候單元測試也在往集成測試遷移，這是一個順其天然的過程，同時爲集成測試的簡化也提供了極大的便利。

2.4 怎麼進行有效的單元測試（HOW）

單元測試最終呈現出來的效果仍是一個或多個測試方法而已，編寫這些測試方法時，應該注意如下原則

Arrange 用於初始化一些被測試方法須要的參數或依賴的對象。
Act方法 用於調用被測方法進行測試。
Assert 用於驗證測試方法是否定期望執行或者結果是否符合指望值

在這以前，咱們固然須要區分出應用程序的每一個基本單元，這裏有個討巧的方法，就是對項目依賴進行自底而上的遍歷便可，咱們並不須要多在乎單元測試和集成測試的依賴關係。

其實在傳統的DDD驅動開發中，咱們已經見識了不少IAPPService和IRepository，以及IDomainService的依賴關係了，對於多個基本單元測試組裝的集成測試，咱們這裏也統一當作同一種東西來對待了，畢竟咱們關注的仍是測試自己。所謂工欲善其事必先利其器，.NET 平臺上強大的工具也是必不可少的，下文中將用XUnit和NSubstitute來進行全部的測試用例展現。

——未完待續