困惑：單元測試該在何時寫？

原文：http://www.codinghorror.com/blog/2005/04/good-test-bad-test.html

做者： Jeff Atwood

不少年以來，用於隨機測試（ad-hoc test）的工具我都是本身開發的。但在最近的一個項目中，我終於採用了NUnit和TestRunner來作正式的單元測試。下面是我編寫的第一個單元測試，看起來很簡單，並且輕輕鬆鬆就經過了：

<TestFixture()>_

PublicClass UnitTests

 

  Private _TargetString As String

  Private _TargetData As Encryption.Data

 

  <TestFixtureSetUp()> _

  Public Sub Setup()

    _TargetString = "an enigma wrapped ina mystery slathered in secret sauce"

    _TargetData = NewEncryption.Data(_TargetString)

  End Sub

 

  <Test(),Category("Symmetric")> _

  Public Sub MyTest()

    Dim s As New Encryption.Symmetric(Encryption.Symmetric.Providers.DES)

    Dim encryptedData As Encryption.Data

    Dim decryptedData As Encryption.Data

 

    encryptedData = s.Encrypt(_TargetData)

    decryptedData = s.Decrypt(encryptedData)

   

    Assert.AreEqual(_TargetString, decryptedData.ToString)

  End Sub

 

EndClass

 

這個測試系統真是太棒了，由於我一眼就能看出這塊代碼在測什麼，以及它是如何工做的。這不由讓人感嘆：簡單就是美！因而，實現單元測試的框架已經不成問題。問題在於，要決定測什麼，以及如何去測。或者再把問題理論化一點：怎樣纔算是好的測試？

單元測試的價值是毋庸置疑的！跟大多數開發人員所作的測試比起來，即便是最最基本的單元測試（就像上面給出的例子那樣），也是巨大的進步。也就是說，大部分開發人員根本就不作測試！他們只是隨意輸入一些數據，而後點幾個按鈕。若是在這個過程當中沒有發現還沒有處理的異常，他們就以爲代碼已經夠好了，能夠交付給測試團隊了……

單元測試的真正價值在於，它迫使你停下來，爲測試思量一番。跟漫無計劃的隨機測試比起來，單元測試讓你爲你剛剛寫下的代碼思考一連串艱難但又不得不考慮的問題：

• 我該怎樣測試這塊代碼？
• 我該執行何種測試？
• 一般的狀況是怎樣的？
• 可能碰到的異常狀況有哪些？
• 我有多少外部依賴關係？
• 我可能會碰到哪些系統故障？

單元測試並不會保證軟件最終能正確工做。我以爲抱有那種指望也是不合理的。但編寫單元測試確實保證了開發人員想過了那些至關棘手的測試問題，哪怕他們只是粗略地想了一下。不用懷疑，只要作了單元測試，咱們就已經在正確的方向上前進了一步。

關於單元測試，我也確實有一些其餘的糾結。好比，如何在單元測試與大規模的代碼重構之間找到平衡——在我作過的全部項目中，在開發的早期階段大都要進行重構。其實，Unicode Andy也有一樣的糾結：

在單元測試方面，我當前遇到的主要問題是，當我修改設計的時候，就會有一大堆測試通不過。這意味着，我要麼少寫一點測試，要麼儘可能少作大的設計修改。但二者都是不理想的。

爲了不這個問題，我只能退而求其次——測試晚一點再介入——但這又跟新潮的「測試驅動開發」模式背道而馳。編寫單元測試是必要的，積極地重構代碼也是必要的。你是如何來平衡的呢？先寫測試的方式能夠減小代碼重構的負擔嗎？或者在設計穩固以後再增長單元測試？