[心得]打造可維護軟體10-自動化測試

  • 1395
  • 0
  • 2017-09-07

打造可維護軟體第十章-自動化測試

自動化測試的指導方針為:

對程式碼進行自動化測試

進行自動化測試對於提高軟體可維護性是很基本明確的道理,只是到底要寫到多完整?作者建議覆蓋率應該在80%以上才夠。

如何遵守此指導方針

重點就是要寫單元測試(Unit Test)以測試程式邏輯,提高可維護性,並搭配自動化工具進行測試。

TDD

這本書對於自動化測試的價值就到此為止,至於為什麼要寫Unit Test、甚麼是Unit Test、如何寫好Unit Test、如何衡量可測性、寫不寫Unit Test的比較,這些問題我覺得In 91大大寫的文章In 91 | 30天快速上手TDD寫的更完整且清楚。

單元測試的基本概念

  • 因為要測試目標(Class及Method)的正確性,所以Unit Test中程式碼應該要簡單及獨立。不能依賴(使用)目標class的method進行邏輯處理。
  • 測試案例之間沒有任何相依性,也不能有順序關係
  • 測試案例要可以重複測試,不會有任何作用
  • 只測試目標Class對外開放的method
  • 寫起來礙手礙腳的,可能是目標Class的耦合性太高

更詳細的概念及原則可以參考In 91 | Unit Testing 簡介

還有一件事,不要把整合測試單元測試搞混。In 91 | 單元測試的意義

如何寫Unit Test

Unit Test應該是很單純,很直覺的。基本上測試程式碼都是Unit Test 3A原則:

  • Arrange: 初始化目標物件、相依物件、方法參數、預期結果
  • Act: 執行測試目標方法
  • Assert: 進行驗證

較為完整的Unit Test大都會牽涉到Resource的初始化及清理,所以需要Test Framework 的支援。如果使用Visual Studio,就會使用到MS Test Framework的skeleton設計Unit Test的執行生命週期,可以參考Kenming's 鮮思維 | 一個最基本的 C#.NET 單元測試程式碼骨架 for VS.NET 2015。要了解如何使用Visual Studio以快速的建立Unit Test,可以看In 91 | 動手寫 Unit Test。雖然文章中寫的是Visual Studio 2010,但即使到了Visual Studio 2017,架構及操作方式都大致相同。

可測性

開始寫了一些Unit Test之後,可能會發現自己寫的Code不好進行測試,因為程式邏輯與太多的東西相依在一起了。例如檔案、資料庫、其他人的Library、甚至是.NET Framework。這也代表著,程式碼存在著改善空間,可以讓它的相依性更低一些。這意味著,要提高可測性讓測試進行得更順利,其實跟提升可維護性是同一條路的。甚麼是可測性呢?可以參考In 91 | 如何隔離相依性 - 基本的可測試性

Fake物件與DI

再繼續深入下去,就會了解到 - 為了讓單元測試更單純更明確的只測試單一邏輯,則需要利用Fake物件取代外部物件,以隔離掉外部物件的影響。要理解如何實作,就需要先了解DIIoC是甚麼。可以參考Huan-Lin 學習筆記 | Dependency Injection 筆記。有了這些概念,就可以依據我們想要測試的情境,選擇哪一種Fake物件-In 91 | Unit Test - Stub, Mock, Fake 簡介

NSubstitute

在測試時,我們可以自己建立Fake物件,但更好的做法是使用Mock Framework以減低我們撰寫測試程式碼的負擔。目前我使用的Mock Framework是NSubstitute。他的概念很簡單,主要是可以簡單的控制Fake物件method屬性的回傳值,這樣我們就可以精準地控制外部物件的行為,以測試目標物件method的運作邏輯。NSubstitute的使用,可以參考搞搞就懂 | NSubstitute 功能實作簡介

Refactoring

在這往覆地過程中,就會發現我們的程式碼需要做一些更動以提升可維護性及可測性。又或者是寫好測試程式後,比較敢修改一些陳年老Code了。這時候,許多的重構手法就需要拿出來使用了。In 91 | Refactoring legacy code 簡介