所以說，TEST FIRST是提高測試代碼正確性的一個很好的途徑。這里先寫開發代碼后寫測試代碼的方式，其實說白了，是我想說的第三點，那樣的測試，真的就很容易成了為了測試而測試的代碼（記憶里，以前我這么做的時候，還都是為了測試而測試，呵呵，不知道其他朋友會如何）。
二、只寫出需求測試（注意，是目標代碼需求，這個代碼的用戶當然是自己了，^_^）
前面說到，要保證測試代碼的正確性，從保證代碼本身的清晰來入手，只寫需求測試也是一個道理，不過要把它放在這里，主要也還是因為自己以前寫測試的時候，往往都很容易忘記這一點，簡單的比方說，當一個測試會牽涉多個類的時候，本來其實也很明確的，單元測試嘛，你測試你的目標類就OK了唄，但是每個人的認識不同，寫測試的水平不同，更在于小心謹慎，總是在寫目標類測試的時候，想這個地方雖然是A類做的事情，不過我也連帶著加個斷言看下A做對了沒有吧，反正也就多加一句，以防萬一嘛（太小心了，其實過界了都不知道）。別小看一行代碼，我的感覺，超過20行（空行不算，sweat）的一個方法在你寫完這個方法幾個月后回來看，暈的幾率很大，至少要立刻明白這個方法的內部結構是基本不能。積少成多，如果目標類關聯了A、B、C、D、E五個甚至更多，多出來的恐怕就不是一、二行代碼了，而且你一次小心一定會多次小心的，比如，在一個測試用例中（我所指的測試用例不是指TESTCASE類，而是該類中的一個TEST方法）你的斷言中包含了對A的一個操作結果的測試，那么在另一個測試用例中，如果還用到A的這個操作，我肯定你還會寫這個斷言，因為你第一次的小心不是偶然。人說，小心使得萬年船，不過，杞人憂天就過猶不及了。而寫測試的時候，是很容易就會犯這樣的錯（唉，其實是我當初很容易犯這樣的錯，sweat）。
所以，職責分明，只寫你需要的你該做的測試，別一開始就懷疑這個懷疑那個，處處小心，步步為營。我們要如何使用我們的代碼，那么就寫那樣的測試，現在我都是拿測試代碼當例子，寫了一個公共模塊，除了有文檔以外，都是建議要是覺得看文檔麻煩就看測試代碼如何使用，或者你干脆就拷貝我的測試代碼過去改下用好了。
三、不要為了測試而測試（這句話是和一個朋友聊天時他說是他和Kent Back交流時Kent Back提醒他的，這里我也不是很確定對這句話的理解的正確與否，因為理解一句話，上下文也是關鍵的，而我并不很了解我朋友同Kent Back談話的具體內容和過程，不過這里還是作為一個要點談談自己的想法）
不要為了測試而測試，^_^，雖然說要寫測試，不過大家都是開發的，如果你的測試代碼的目的成了測試，我還是會說你這就不夠“專業”了。（這句有點耳熟，星星：拜托，雖然大家都是中國人，你要是抄我臺詞，照樣要告你剽竊）
其實開始我聽朋友講這句，似懂非懂，因為畢竟只是一句沒頭沒尾的話，聽過就算了。但是細細品了，確覺得有些道理（^_^，不知道我的想法是不是Kent Back說這句話的本意）。言歸正傳，開發人員的測試代碼，還是不要以測試目標代碼為目標的好，這樣才能更好的確保測試代碼的正確性。
這里要澄清的是，不是說測試代碼就不要去拿來測試了，呵呵，測試代碼的結果（無論是否測試先行）其實都是一樣的，都是可以自動（或者半自動，^_^）執行的測試，我說了，是寫測試的目的，由于你的目的不同，中間的過程也是大不相同的，對于開發人員來說，開發代碼是最終目的（什么需求分析、系統設計啦等等等等，還不是為了能滿足用戶需求的代碼出來給用戶跑嘛，哦，當然，最最終目的，咱還是靠這個養家糊口，sweat），所以開發過程中的單元測試代碼，它只是輔助我們開發的（這點好像說了好多遍了，sweat，別丟我臭雞蛋），所以這些測試代碼的最終目的也是為了開發代碼，它和測試人員寫的測試代碼有本質的區別（測試人員要是來看我這篇文章，嘿嘿，SORRY啦，真不是為測試寫的）。
說得好繞口，不過，只有清楚了這點，那么前面2點才會站得住腳，如果一開始得測試代碼就只是為了測試目標代碼得功能，那么TEST FIRST就是笑話了，連目標都沒有怎么可能測試，而根據需求寫測試，根本不管內部邏輯以及邊界條件等等等等什么這覆蓋那覆蓋的測試，測試人員一定說我瞎掰了，這也能拿來測試？
所以，要保證測試代碼的正確性，別為了測試而測試，只有不為了測試而測試，你才會真正做到第一、二點。（好像這點應該擺第一去，sweat，不過既來之則安之落）
四、每次寫一點（原子級）測試
這一點，其實說白了，是XP中的小增量迭代，測試驅動開發強調雖然是測試優先，但是測試開發并行過程中相互的交互作用是很關鍵的。
一個很籠統的測試用例，既測試這個又測試那個，難免會復雜起來（量的積累帶來質的變化），所以最好是一個測試用例只針對一個需求寫測試，少量多次嘛。添加一點測試，運行失敗，修改代碼，運行測試，直到成功，然后重構代碼，最后測試通過，是測試驅動開發的一個小迭代周期，當然迭代周期的控制是可以因人而異的。
每次寫的測試越少，那么表示你關注的問題或者需求就越少，那么精力就越集中，相對的測試的代碼量也越少，大問題通常都可以通過將其拆分成多個小問題分別解決來得到解決，如果覺得測試代碼太復雜，自然也可以通過拆分復雜的測試代碼為多個小的相對簡單的測試代碼段來縮小其復雜性。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
