代码之家  ›  专栏  ›  技术社区  ›  anonymous

TDD:从何处开始第一次测试[关闭]

  •  15
  • anonymous  · 技术社区  · 16 年前

    我目前的项目是重新设计一个现有的系统,作为公司组装过程的一部分生成序列号。通过查看现有系统,我对当前流程和工作流程有了了解。我还有一个新需求列表,以及它们将如何修改工作流程。

    我觉得我已经准备好开始写程序了,我决定强迫自己最终从头到尾做TDD。

    但现在我不知道从哪里开始。(我还想知道我是否已经对用户的程序流程有了概念,从而欺骗了TDD过程。)

    • 用户提交生产订单号,并收到该订单物料清单的可序列化零件号列表

    当用户选择一个零件号时,开始下一步。

    所以我想我可以用这第一步作为起点。我知道我想要一段代码,它接受生产订单号并返回零件号列表。

    // This isn't what I'd want my code to end up looking like
    // but it is the simplest statement of what I want
    IList<string> partNumbers = GetPartNumbersForMfgOrder(string mfgOrder);
    

    一方面,这看起来是一个糟糕的开始——一个非常普通的高级函数。另一方面,我觉得如果我从一个较低的层次开始,我只是在猜测我可能需要什么,这似乎是反TDD的。


    作为旁注。。。这就是你使用故事的方式吗?

    作为装配工 我想得到一份生产订单上的零件号清单 这样我就可以选择序列化哪一个了

    作为装配工 我想用序列号标记零件

    4 回复  |  直到 16 年前
        1
  •  16
  •   Eduardo Scoz    16 年前

    以下是我将如何开始。假设您完全没有此应用程序的代码。

    1. 从UI开始。创建一个非常简单的页面(假设它是一个web应用程序),包含三个字段:标签、列表和按钮。这很好,不是吗?用户可以复制列表并发送到inv系统。
    2. 使用模式作为设计的基础,如MVC。
    3. Assert.AreSame(3, controller.RetrieveParts(mfgOrder).Count)
    4. 编写控制器的简单实现,以确保返回某些内容: return new List<MfgOrder>{new MfgOrder(), new MfgOrder(), new MfgOrder()};
    5. 现在你的UI工作了!工作不正常,但正在工作。因此,让我们期待控制器从服务或DAO获取数据。在测试用例中创建一个模拟DAO对象,并添加调用方法“partsDao.GetPartsInMfgOrder()”的期望。
    6. 使用该方法创建DAO类。从控制器调用该方法。您的控制器现在完成。
    7. 继续迭代,直到完成所有操作。过一会儿,你就会习惯的。

        2
  •  3
  •   Gishu    16 年前

    这是一个非常好的开始测试。通过这一点,您可以定义预期的行为——它应该如何工作。现在,如果你觉得自己吃了一口比你想吃的大得多的东西。。您可以暂时忽略此测试,并编写一个更细粒度的测试,将部分或至少中途删除。然后是其他的测试,让你朝着第一个大考通过的目标前进。每一步都进行红-绿重构。

    小测试,我认为意味着你不应该在一次测试中测试很多东西。e、 在我用这些参数调用了Method1()、Method2()和Method3()之后,g是state1、state2和state3中的组件D.A、B和C。 每个测试应该只测试一件事。你可以搜索优秀测试的质量。但我认为你的测试是一个小测试,因为它是 简短且专注于一项任务

    使现代化 :作为一个尝试建议(来自贝克的书),你可能想坐下来,在一张纸上列出SUT的单线测试列表。现在您可以选择最简单的(您有信心能够完成的测试)来建立信心。或者你可以尝试一个你有80%自信但有一些灰色区域(也是我的选择)的方法,因为这将帮助你在学习过程中了解SUT。保留那些你不知道如何进行到底的。。。希望在容易的事情完成时,情况会变得更清楚。当它们变成绿色时,一个接一个地把它们去掉。

        3
  •  1
  •   JB King    16 年前

    我认为你有一个很好的开始,但不是这样认为的。这个应该产生更多测试的测试对我来说完全有意义,就好像你仔细想想,你知道生产订单号或零件号是什么吗?你必须构建那些可能导致其他测试的测试,但最终你会进行一些小测试,我相信。

    • 作为一个用户,我希望提交一个生产订单号,并收到该订单物料清单的可序列化零件号列表

        4
  •  1
  •   cwap    16 年前

    好吧,好吧,你碰到了我第一次尝试TDD时碰到的墙:)

    从那以后,我放弃了它,仅仅是因为它使得重构成本太高——而且我在开发的初始阶段往往会进行大量重构。

    我发现TDD最受监督和最重要的方面之一是,它迫使您在实际实现类接口之前定义类接口。当您需要将所有零件组装成一个大产品(嗯,组装成子产品)时,这是一件非常好的事情。在编写第一个测试之前,您需要做的是在编码之前准备好您的域模型、部署模型,最好是一大块类图——这仅仅是因为您需要识别不变量、最小值和最大值等,然后才能测试它们。您应该能够在设计的单元测试级别上识别这些。

    Soo,根据我的经验(不是一些喜欢将真实世界的类比映射到OO:P的作者的经验),TDD应该是这样的:

    1. 根据需求规范创建您的部署图(ofc,没有什么是一成不变的)
    2. 创建或修改域模型以包含此故事
    3. 识别测试向量。
    4. 根据在步骤4中创建的接口创建测试
    5. 测试测试(!)。这是非常重要的一步。。
    6. 去和你的同事喝杯啤酒:)