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

原則：Write the Tests First

原則：Design for Testability

原則：Use the Front Door First

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

原則：Communicate Intent

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

原則：Don’t Modify the SUT

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

原則：Keep Tests Independent

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

原則：Isolate the SUT

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

原則：Minimize Test Overlap

最小化重復(fù)的測試。我們知道，測試案例的組合是無窮無盡的，我們不可能覆蓋所有的組合。但我們可以選擇最佳的組合。對(duì)被測代碼的同一個(gè)條件進(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

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

原則：Test Conerns Separtely

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

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

原則：Ensure Commensurate Effort and Responsibility

編寫和維護(hù)測試案例的時(shí)間，不能超過實(shí)現(xiàn)產(chǎn)品代碼的時(shí)間。因此，要平衡好測試與開發(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)容還不錯(cuò)，歡迎將生活随笔推薦給好友。