业务应用程序的 TDD 示例

Question

我了解有关单元测试的一般思想，并已在系统中发生复杂交互的场景中使用它，但我仍然对所有这些原则结合在一起有疑问。

我们被警告不要测试框架或数据库。好的 UI 设计不适合非人工测试。 MVC 框架不包括一般的 UI 交互。在许多应用程序中还剩下什么？ 37signals 谈到了广泛的单元测试，但在 Basecamp 或 Backpack 这样的应用程序中，通过适当的单元测试测试的事物类型究竟是什么？在这种情况下，100% 的代码覆盖率意味着什么？

编辑:我不是要拆除像 Backpack 这样的应用程序——它们很棒，但这项工作似乎更多地涉及设计和交互，而不是复杂的逻辑(事实上，他们支持这个想法)。在该应用程序的那些区域中，CRUD 以及与哪个对象相关的层次结构几乎涵盖了它，单元测试的适当数量是否为零？在这种情况下，测试点是否是验证代码的另一个副本(必需的、正则表达式等)？

Answer 1

业务应用程序的 TDD 就是这样工作的。

写下业务需求。

写下针对该需求的测试。

编写通过测试的代码。

诀窍是有许多不需要大量测试的垃圾非业务需求。

“保存到数据库”不是业务需求。这是技术性的。

“在某些情况下激活 GUI 上的按钮”不是业务需求，而是界面的一部分。

“备份”不是业务需求；它是安全性或业务连续性或其他什么。

考虑一个具体的例子。

要求——“在你支付罚款之前你不能借书。”

测试。

尝试借书罚款。

尝试借书而没有罚款。

代码。

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% 吗？它不会那样工作。测试每一行代码并没有涵盖所有逻辑路径，所以不要担心并开始测试。

测试业务用例。如果他们通过了并且有未经测试的代码，那么——也许——你写了太多的代码。