測試驅動開發上的五大錯誤(5)

　　18. Assert.AreEqual("sp-001", product.ID);

　　19. Assert.AreEqual("Super Product", product.Name);

　　20.}

　　4、先寫程序后寫測試

　　我堅持認為，驅動測試開發的意義遠高于測試本身。正確的實施驅動測試開發能巨大的提高開發效率，這是一種良性循環。我看到很多開發人員在開發完某個功能后才去寫測試方法，把這當成一種在提交代碼前需要完成的行政命令來執行。事實上，補寫測試代碼只是驅動測試開發的一個內容。

　　如果不是按照先寫測試后寫被測試程序的紅，綠，重構方法原則，測試編寫很可能會變成一種體力勞動。

　　如果想培養你的單元測試習慣，你可以看一些關于TDD的材料，比如The String Calculator Code Kata。

　　5、測試的過細

　　請檢查下面的這個方法：

　　1.public Product GetByID(string id)

　　2.{

　　3. return _productRepository.GetByID(id);

　　4.}

　　這個方法真的需要測試嗎?不，我也認為不需要。

　　驅動測試純粹主義者可能會堅持認為所有的代碼都應該被測試覆蓋，而且有這樣的自動化工具能掃描并報告程序的某部分內容沒有被測試覆蓋，然而，我們要當心，不要落入這種給自己制造工作量的陷阱。

　　很多我交談過的反對驅動測試開發的人都會引用這點來作為不寫任何測試代碼的主要理由。我對他們的回復是：只測試你需要測試的代碼。我的觀點是，構造器，geter，setter等方法沒必要特意的測試。讓我們來加深記憶一下我前面提到的經驗論：

　　為方法里的每個IF，And，Or，Case，For，While等條件寫出獨立的測試方法。

　　如果一個方法里沒有任何一個上面提到的條件語句，那它真的需要測試嗎?

　　祝測試愉快!

原文轉自：http://www.vaikan.com/top-5-tdd-mistakes/