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

　　26. // Act

　　27. decimal standardPrice = product.CalculatePrice(CalculationRules.Standard);

　　28.

　　29. // Assert

　　30. Assert.AreEqual(12m, standardPrice);

　　31.}

　　32.

　　33.[TestMethod]

　　34.public void NoDiscountRuleReturnsBasePrice()

　　35.{

　　36. // Arrange

　　37. var product = new Product()

　　38. {

　　39. BasePrice = 10m

　　40. };

　　41.

　　42. // Act

　　43. decimal basePrice = product.CalculatePrice(CalculationRules.None);

　　44.

　　45. // Assert

　　46. Assert.AreEqual(10m, basePrice);

　　47.}

　　注意這些非常具有描述性的測試名稱。如果一個項目里有500個測試，其中一個失敗了，你能根據名稱就能知道哪個測試應該為此承擔責任。

　　這樣我們可能會有更多的方法，但換來的好處是清晰。我在《代碼大全(第2版)》里看到了這句經驗之談：

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

　　驅動測試開發純粹主義者可能會說每個測試里只應該有一個斷言。我想這個原則有時候可以靈活處理，就像下面測試一個對象的屬性值時：

　　01.public Product Map(ProductDto productDto)

　　02.{

　　03. var product = new Product()

　　04. {

　　05. ID = productDto.ID,

　　06. Name = productDto.ProductName,

　　07. BasePrice = productDto.Price

　　08. };

　　09.

　　10. return product;

　　11.}

　　我不認為為每個屬性寫一個獨立的測試方法進行斷言是有必要的。下面是我如何寫這個測試方法的：

　　01.[TestMethod]

　　02.public void ProductMapperMapsToExpectedProperties()

　　03.{

　　04. // Arrange

　　05. var mapper = new ProductMapper();

　　06. var productDto = new ProductDto()

　　07. {

　　08. ID = "sp-001",

　　09. Price = 10m,

　　10. ProductName = "Super Product"

　　11. };

　　12.

　　13. // Act

　　14. Product product = mapper.Map(productDto);

　　15.

　　16. // Assert

　　17. Assert.AreEqual(10m, product.BasePrice);

　　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.aqee.net/top-5-tdd-mistakes/