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

时间:2010-06-18 19:00:06

标签: unit-testing tdd bdd storyboard principles

3 个答案:

答案 0 :(得分:6)

你想通过以下方式偏离轨道:“......如果没有其他一些作品,你就不能拥有一件......”

故事分裂是一项技能。这需要练习,而且很难成为擅长。 This page解释了这个概念并提供了有关故事分裂的资源的链接。

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

  

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

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

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

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

  3. 作为BA,由于“无法访问数据库”导致订单输入失败,我希望通过电子邮件发送到SA列表时出现错误消息“无法通过网络问题查找客户信息的数据库”这样就可以分析和改进数据库/网络问题。

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

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

答案 1 :(得分:3)

你绝对不能直接跳到你最高级的故事(x12文件翻译,yikes) - 当你处理一个不成熟的系统时,你必须将大量复杂的功能分解成可以在其中估计和传递的可理解的故事。迭代。

我将从您的第二个用户故事开始,我希望这足够了:

  

作为系统分析师监控   系统当用户输入时   导致未处理的功能   错误我想要的当前状态   应用程序,异常抛出和   堆栈跟踪输入到日志中   发送电子邮件给系统分析员   分发名单。

我首先将其分解为两个用户故事:

1)作为监视系统的系统分析员,当用户输入导致未处理错误的函数时,我想要应用程序的当前状态,抛出异常并将堆栈跟踪输入到日志中以便我可以诊断什么发生了,并开始纠正问题。

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

由于现代开发平台(及其开源社区)使得日志记录变得微不足道,您甚至可能甚至不需要将第一个作为用户故事明确表达出来。

假设您已经开始注销第二个用户故事。如果您没有使用库来为您处理电子邮件,您可以立即开始练习测试驱动开发,只需考虑您要在全局错误处理程序中执行的操作(已经记录了未处理的异常)。它需要:

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

开始考虑将要做这些事情的类,存根接口,并编写一些测试。

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

答案 2 :(得分:2)

我已经做了一些工作,所以这里有一些我写的东西可能会有所帮助:

将愿景分解为功能,故事,场景和代码:

http://www.infoq.com/articles/pulling-power

拆分故事:

http://lizkeogh.com/2008/09/11/splitting-up-stories/

处理技术故事(记录等):

http://lizkeogh.com/2008/09/10/feature-injection-and-handling-technical-stories/

欢迎所有反馈。