如何正确创建功能,测试,故事并将其分解

Question

我试图掌握整个TDD方法,因此,我真的不知道如何将其作为一个很简洁的问题来呈现,所以这里是冗长的版本.我似乎正在经历保龄球(马丁),钱(羽毛)和其他类似的游戏/简单示例和功能齐全的企业应用程序之间的差距.

我试图弄清楚我是否遗漏了类似功能概念的东西,据我所知,这是增加商业价值的东西,或者在做TDD时如何正确地分离问题以及每种方法如何适用于另一个.如果对功能的定义是一个很难的规则,那么记录和错误报告等功能就不是特征.这是否意味着TDD不提供记录和通知的方法？

不是试图开始任何战争,我很确定事实并非如此,所以我告诉自己"商业价值"必须将中间应用从客户业务价值转移到业务(应用的创建者)业务价值.

所以我然后尝试将其切换为这个常见示例From:作为数学白痴当我输入2时,按add,输入2,然后按=我想要4返回.

要:作为监视系统的系统分析员当用户输入导致未处理错误的函数时,我想要应用程序的当前状态,抛出异常并将堆栈跟踪输入到日志中并向系统分析员分发列表发送电子邮件.

然后:作为业务分析师确保所有客户订单得到处理当用户提交电子订单并且路由或会计信息未验证时,我希望将无效的会计和路由信息输入到日志中并通过电子邮件发送附带的订单文件业务分析师用户组.除非问题是因为无法访问数据库以查找由于网络问题导致的客户信息,请输入"无法访问数据库以查找由于网络问题导致的客户信息",并将错误消息发送到系统分析师分发清单.

然后开始扩展到我认为完全不可接受的东西:作为电子订单完成检查当收到订单时,我想检查x12文件是否被翻译成平面文件,如果它未通过验证或翻译日志并通过电子邮件发送错误,则提取订单信息和状态并将其加载到数据库中文件被发送到队列到as400并且状态更新到数据库as400发送确认他们收到订单并且状态更新到数据库as400发送一个flatfile确认并且状态更新到数据库确认转换为x12并且状态更新到数据库,x12确认被正确路由,状态更新到数据库,确认发送到数据库客户和状态更新到数据库如果x12包含无效数据记录错误,发送电子邮件,如果平板文件没有在2分钟内拉出队列记录错误,发送电子邮件等n与x电源可能的错误情况.

即使您将每个功能分解为自己的"功能",您仍然会遇到日志问题,通知系统分析员应用程序发生异常或发生网络错误或找不到数据库等,或者业务组发现具有无法识别的帐号的订单是将这些中的任何一个添加到类中,作为方法,属性等似乎违反了单一责任原则.大约那个时候事情开始旋转,我头晕,气短和心悸

所以,既然我对此感到困惑,以至于我不知道如何将其作为一个清晰的问题,我会试着总结一下.

你如何确定何时/何地以及如何分解这些东西并将它们分开？很容易说将它们分解成提供商业价值的最小部分,但是当你不能拥有一件没有其他部分时,那么"真正的"答案是什么？所有这些都不适合一个粘性.

我愿意接受包含更多书籍,教程和视频的答案,但我认为,如果有一些真实世界的应用程序可以解释这些类型的东西,这些应用程序遵循可能提供最大价值的敏捷和TDD原则？不可否认,我对此比较陌生,但我已经阅读了Martin/Feathers/Osherove的书籍,我看过很多关于井字游戏,保龄球,素数等的katas,但是没有记录,没有错误报告没有这种"现实世界"的东西.

---

让我尝试别的.

我通过ftp从大型机获取一个文件,列出要与我们的供应商一起下的订单,这个文件称为摘要文件.我每5分钟检查一次这个文件.当有一个文件我解析它然后检查以确保我们通过MQ收到了这个摘要文件中列出的每个订单.作为双重检查,我还检查订单是否存在,因为如果未收到摘要文件,我们无法确保收到所有订单.有了这样说,以下看起来似乎我朝着正确的方向前进？

Feature: Check for the presence of a summary file
  In order to verify all orders were sent through MQ from the mainframe
  a summary file must be found to determine the expected orders.

  Scenario: A summary file has not been sent
    Given a summary file does not exist
    When I check for the existence of a file
    Then I should sleep for 5 minutes

  Scenario: A summary file has been sent
    Given a summary file does exist
    When I check for the existence of a file
    Then I should validate the summary file

Feature: Validate the summary file
  In order to process a summary file
  summary file must be valid

  Scenario: A valid summary file exists
    Given a valid summary file
    When I validate the summary file
    Then I should upload the order details to the order details DB.

  Scenario: An invalid summary file exists
    Given a invalid summary file
    When I validate the summary file
    Then I should log the errors encountered
    And email the erroneous file to the analyst email group

再次重复该操作,用订单替换摘要.这就是我想出来的.

Answer 1

你会想到:"......如果没有其他一些作品,你就不能拥有一件......"

故事分裂是一项技能.这需要练习,而且很难成为擅长.此页面解释了该概念,并提供了有关故事分割的资源的链接.

以下是您在分手时遇到问题的一个想法:

作为业务分析师,确保所有客户订单得到处理当用户提交电子订单并且路由或会计信息未验证时,我希望将无效的会计和路由信息输入到日志中并通过电子邮件与附加到业务分析师用户的订单文件一起发送组.除非问题是因为无法访问数据库以查找由于网络问题导致的客户信息,请输入"无法访问数据库以查找由于网络问题导致的客户信息",并将错误消息发送到系统分析师分发清单.

我看到该段中至少有4个故事:

1. 作为BA,在由于无效的帐户和路由信息导致订单输入失败期间,我希望帐户和路由信息通过电子邮件发送到带有订单文件的BA组,以便有人知道获取正确的信息并重新输入订单.

2. 作为BA,在由于无效的帐户和路由信息导致订单输入失败期间,我希望输入到日志中的帐户和路由信息,以便e具有无效信息的永久记录.

3. 作为BA,在由于"无法访问数据库"导致订单输入失败期间,我希望通过电子邮件发送到SA列表的错误消息"无法通过网络问题查找客户信息的数据库"以便数据库/网络问题可以进行分析和改进.

4. 作为BA,由于"无法访问数据库"导致订单输入失败,我希望将错误消息"无法访问数据库以查找因网络问题而导致的客户信息"写入日志,以便我们拥有永久记录数据库/网络问题

如果你的团队做得好TDD,那么分别实现这些故事应该不会太困难.您的代码将受到测试保护,以便如果在卡4上工作的人打破了卡1的功能,希望测试能够捕获它.

Answer 2

你绝对不能直接跳到最高级的故事（x12 文件翻译，哎呀）——当你处理一个不成熟的系统时，你必须将巨大的复杂功能分解成可理解的故事，你可以在迭代中估计和交付这些故事。

我将从你的第二个用户故事开始，我希望这已经足够了：

作为监视系统的系统分析师，当用户输入导致未处理错误的函数时，我想要应用程序的当前状态、引发的异常和堆栈跟踪输入到日志中，并向系统分析师分发列表发送电子邮件。

我首先将其进一步分解为两个用户故事：

1）作为监视系统的系统分析师，当用户输入导致未处理错误的函数时，我希望将应用程序的当前状态、引发的异常和堆栈跟踪输入到日志中，以便我可以诊断发生的情况并获取纠正问题的先机。

2）作为监控系统的系统分析师，每当出现未处理的错误时，我希望通过电子邮件收到通知，以便我更有可能及时解决问题。

您甚至可能不需要将第一个故事本身阐明为用户故事，因为现代开发平台（及其开源社区）使日志记录变得微不足道。

假设您让企业签署了第二个用户故事。如果您没有使用库来为您处理电子邮件，您可以立即开始练习测试驱动开发，只需考虑您想要在全局错误处理程序中执行的操作（已记录未处理的异常）。它需要：

• 获取收件人列表的一个或多个电子邮件地址。
• 获取主题行。
• 获取任何附加内容。
• 通过您使用的任何机制发送邮件。

开始考虑将执行这些操作的类、删除接口并编写一些测试。

您对要求的进一步阐述都是附加功能。您的下一个要求将需要将不同类型的信息写入日志。之后，您需要能够向电子邮件添加附件。就这样继续下去。每个故事可能涉及多个类，因此单一责任原则不应成为障碍。