【问题标题】:Test driven development - when/what to test?测试驱动开发——何时/测试什么?
【发布时间】:2013-04-19 08:40:18
【问题描述】:

我正在尝试开始使用 TDD,但我马上就不确定我应该在何时以及应该测试什么。我正在做的一个新项目中的前两个任务如下。

1) 在 REST 端点上接收一些 JSON 格式的数据并将其保存在数据库中。假设数据是几条汽车记录-

{ “汽车”: [{ “制造”:“福特”, “颜色”:“蓝色”, “年”:“2010”, “出售”:真 }, { “制造”:“宝马”, “颜色:黑色”, “年”:“2011”, “出售”:假 } ] }

因此数据到达 REST 端点,我需要将其保存在数据库中。我是否需要对这项任务进行测试?如果需要,它应该是什么样的?

2) 从数据库中检索一些记录并将它们显示在视图/网页中(即使用一些模板系统)。假设记录是上面的汽车记录,它们应该显示如下 -

<ul id="cars">
    <li id="car-1">
        <div><span>Make:</span><span>Ford</span>
        </div>
        <div><span>Color:</span><span>blue</span>
        </div>
        <div><span>Year:</span><span>2010</span>
        </div>
        <div><span>For sale:</span><span>Yes</span>
        </div>
    </li>
    <li id="car-2">
        <div><span>Make:</span><span>BMW</span>
        </div>
        <div><span>Color:</span><span>black</span>
        </div>
        <div><span>Year:</span><span>2011</span>
        </div>
        <div><span>For sale:</span><span>No</span>
        </div>
    </li>
</ul>

那么我需要对这个任务进行测试吗?如果需要,它应该是什么样子?

【问题讨论】:

    标签: unit-testing testing tdd


    【解决方案1】:

    您使用什么语言、平台等?也许我们可以为您找到一些示例。

    TDD 一开始很棘手,像这样的任务(使用数据库和 Web 部件)需要在多个级别上进行测试。

    首先将任务划分为可以进行单元测试的单一职责(可能映射到类)。例如,一个接受 JSON 输入的类,并用其属性对对象进行水合,TDD 该类。数据库层很难进行单元测试,我们通常使用存储库模式,然后在测试其他类时进行模拟。

    数据库单元测试很难,因此请考虑围绕数据库进行“验收”或“集成”测试。这可能是一个连接到真实测试数据库的测试,放入一些测试数据,再次将其拉出,并验证它看起来是否正确。从理论上讲,您甚至都不关心它是什么数据库,只要您存储的内容再次出现,您就知道它正在工作。

    HTML / web 测试最好使用selenium webdriver 等工具在高级别上完成,它允许您编写启动真实浏览器的测试代码,与您的页面交互,并断言内容/行为是正如预期的那样。

    通过与已经知道它的人结对编程,或者通过参加课程或培训课程来学习这些东西真的很好。还有很多书籍博客和教程,让您在沙盒中学习,这比在实际项目中尝试自己学习更简单,完成工作的压力与学习相冲突。


    编辑:Java 和 Play 框架。 好的,我不知道具体的播放框架,但如果你设置正确,它可能会为你做 JSON 解析,这会将 json 解析函数简化为样板代码。 TDD 在这里没有很大的价值,但如果你愿意,你可以。同样,有一个活动记录风格的数据库层?因此,测试您的库提供的代码并没有太多价值(而且 dbs 对于单元测试来说是困难的/不可能的/毫无意义的*)。


    编辑:编辑 - 这很恶心,显然是Play uses static controller methods which makes it hard to unit test (because you can't inject dependencies - which makes mocking difficult)。如果不进行数小时的研究,恐怕我无法提供具体细节,但集成测试可能是这里的方法,它可以一起测试你的几个代码单元,包括数据库。

    总之:

    • 不要在样板文件上操心 TDD。保持样板和事物的隔离(即控制器只做网络工作,然后交给其他类。存储库只保存和检索对象,而不是规则/决策/操作。
    • 当您开始向应用程序的内部添加更多业务逻辑时 - 将其隔离在业务类中(即 - 远离 Web 或数据库样板),您可以轻松地进行单元测试。绝对是 TDD 这个东西。
    • 尝试在您的应用程序中进行集成测试以测试数据库。在您的应用背后有一个真正的测试数据库,使用该应用保存、检索它,然后断言它是正确的。
    • 使用 Selenium 之类的工具来测试网页。

    *根据你的测试信念删除。

    【讨论】:

    • @AndrewM ,如果一个应用程序是用java编写的,基本上你是说类的作者也应该写一个stub。 1) stub 可以作为另一个作者的不同类别的缺失方法的填充。 2)stub可以用来判断bug是在单元测试时调用作者类的方法还是其他类的被调用方法3)stub可以伪造数据并提供给你的类方法(例如:飞机雷达数据)。因此,基本上是细粒度的单元测试。在 TDD 方法中是否不需要集成测试(不包括 DB)?优势?
    猜你喜欢
    • 1970-01-01
    • 2014-01-30
    • 2011-09-09
    • 2012-10-10
    • 1970-01-01
    • 2010-12-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多