業務應用程序的TDD就是這樣工作的。
寫下業務需求。
寫下該要求的測試。
編寫通過測試的代碼。
訣竅是有很多不需要大量測試的快速非業務需求。
考慮一個具體的例子。
要求 - 「在您支付罰款之前,您不能借書。」
測試。
嘗試借書與罰款。
嘗試借書沒有罰款。
代碼。
class FinesNotPaid(unittest.TestCase):
def setUp(self):
# load some fixtures with users, books and fines outstanding.
def test_should_not_checkout_book(self):
x = TheCheckoutClass()
x.checkoutBook(someBook)
self.fail("Should have thrown error")
class FinesPaid(unittest.TestCase):
def setUp(self):
# load some fixtures with users, books and fines paid.
def test_should_not_checkout_book(self):
x = TheCheckoutClass()
x.checkoutBook(someBook)
self.success()
class NoFines(unittest.TestCase):
etc.
這些是由與您的數據庫和GUI分開的類實現的業務規則。這些是應用程序域層中的類。
您的CRUD規則是業務規則。你需要測試它們。但是,您不需要測試每個與數據庫相關的功能。你需要一些「我可以創建並堅持一個對象嗎?」試驗。你必須相信ORM,數據訪問層和數據庫實際工作。您不要編寫測試來徹底測試ORM的內置功能。
代碼覆蓋率(100%或80%或10%)在很大程度上毫無意義。具有80%代碼覆蓋率測試的軟件實際上可能失敗20%?它不這樣工作。測試每一行代碼並不能覆蓋每條邏輯路徑,因此請不要擔心並開始測試。
測試業務用例。如果他們通過並且有未經測試的代碼,那麼 - 也許 - 你寫了太多的代碼。
它可能會分裂毛髮,但這可能比BDD更適合TDD。這篇文章的結尾很有趣(http://consultingblogs.emc.com/jamesbroome/archive/2009/10/16/asp-net-mvc-controllers-bdd-the-perfect-match-part-3-the -accountcontroller-contd.aspx) – R0MANARMY 2010-05-14 18:11:20
有些人稱之爲DDD - 域驅動開發。 BDD,DDD和TDD之間有很多不必要的分裂。我認爲他們創造了其他條款讓業務分析師感到有用。 – 2010-05-14 19:26:27