自動化測試過程中，有一些基本的原則，就如同宣言(Manifesto)。由于大部分的原則在前面其實都提到的，因此，有的不做太多說明了。

原則：Write the Tests First

原則：Design for Testability

原則：Use the Front Door First

意思是說，從最外層暴露的publish方法開始測試。

原則：Communicate Intent

意思是說，測試案例要意圖明確，這樣才容易理解和維護(hù)。比如，命名時，使用Intent-Revealing Names[SBPP]。參考：http://architects.dzone.com/news/intention-revealing-designs

原則：Don’t Modify the SUT

不要修改被測的對象。但有時需要使用一些Test Double或Fake對象時，要注意每個替代的對象都被測試。舉了個例子，有X,Y,Z三個模塊，X依賴于Y和Z，Y依賴于Z，測試X時，可以使用Test Double代替Y和Z，測試Y時，可以使用Test Double代替Z，但是在測試Z時，不能再把Z替換成Test Double了，因為Z就是被測對象。

原則：Keep Tests Independent

讓測試案例獨立，能夠單獨的執(zhí)行，不依賴于別的案例。

原則：Isolate the SUT

讓SUT獨立，不依賴外部的環(huán)境。SUT往往會依賴一些外部的其他環(huán)境，比如，依賴一個外部的應(yīng)用程序，依賴一個可用的http服務(wù)器等等。這使得測試變得不穩(wěn)定，或者減慢了執(zhí)行的速度。去除SUT依賴的方法是使用Test Double替換掉外部的因素。比如，需要http服務(wù)器，可以自己搭一個假的http服務(wù)器。

原則：Minimize Test Overlap

最小化重復(fù)的測試。我們知道，測試案例的組合是無窮無盡的，我們不可能覆蓋所有的組合。但我們可以選擇最佳的組合。對被測代碼的同一個條件進(jìn)行重復(fù)的測試是沒有多少意義的。

原則：Minimize Untestable Code

最小化不可測試的代碼，方法就是，重構(gòu)！

原則：Keep Test Logic Out of Production Code

上一節(jié)提到了，不要在產(chǎn)品的代碼里添加任何測試的邏輯。比如，像if tesing之類的判斷。

原則：Verify One Condition per Test

解釋的過程中，有個觀點比較有意思。手工測試時，通常會做一些復(fù)雜的操作，復(fù)雜的條件組合在一起，然后看是否出錯。這看起來和自動化測試或單元測試完全相反了，為什么呢？這是因為，人能夠在復(fù)雜的情況下去判斷各種執(zhí)行結(jié)果，并能夠去分析其中的問題。而我們的案例其實并沒有那么智能，為了讓案例能夠更加精確的定位問題，我們只能檢查每個案例只檢查一種情況。

原則：Test Conerns Separtely

Separation of concerns的解釋見：http://en.wikipedia.org/wiki/Separation_of_concerns

這里的意思大概是讓測試案例做好分層，減少重復(fù)的部分，從而更加容易定位問題。

原則：Ensure Commensurate Effort and Responsibility

編寫和維護(hù)測試案例的時間，不能超過實現(xiàn)產(chǎn)品代碼的時間。因此，要平衡好測試與開發(fā)的付出。

轉(zhuǎn)載于:https://www.cnblogs.com/coderzh/archive/2010/01/23/xUnit-Test-Patterns-4.html

總結(jié)

以上是生活随笔為你收集整理的《xUnit Test Patterns》学习笔记4 - Principles of Test Automation的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。