我试图掌握整个 TDD 方法，因此，我真的不知道如何将其作为一个简洁的问题提出，所以这里是冗长的版本。我似乎正在经历保龄球 (Martin)、金钱 (Feathers) 和其他类似游戏/简单示例与功能齐全的企业应用程序之间的差距。
我试图弄清楚我是否遗漏了诸如功能概念之类的东西，据我所知，它可以增加业务价值，或者在进行 TDD 时如何正确分离关注点，以及每个关注点如何应用于另一个。如果对特性的定义是硬性规则，那么日志记录和错误报告之类的东西就不是特性。这是否意味着 TDD 不提供记录和通知的方法？
不想挑起任何战争，我很确定情况并非如此，所以我告诉自己，“商业价值”必须将中间应用程序从客户的商业价值转变为企业（应用程序的创建者）的商业价值。
所以我然后尝试像这个常见的例子一样切换它来自：作为一个数学白痴当我输入 2 时，按 add，输入 2，然后按 = 我要返回 4。
致：作为监控系统的系统分析师当用户输入导致未处理错误的函数时，我想要应用程序的当前状态、抛出的异常和堆栈跟踪进入日志，并向系统分析师分发列表发送电子邮件.
然后：作为业务分析师，确保所有客户的订单都得到处理当用户提交电子订单并且路由或会计信息未验证时，我希望将无效的会计和路由信息输入日志并通过电子邮件与附加的订单文件一起发送到业务分析师用户组。除非问题是由于网络问题而无法访问数据库以查找客户信息 在日志中输入“由于网络问题而无法访问数据库以查找客户信息”并将包含错误消息的电子邮件发送到系统分析师分发列表。
然后它开始扩展到我认为完全不能接受的东西：作为电子订单完成检查收到订单时，我想检查 x12 文件是否已翻译成平面文件，如果验证或翻译日志失败并通过电子邮件发送错误，则提取订单信息和状态并将其加载到平面数据库文件被发送到队列到 as400 并且状态被更新到数据库 as400 发送确认他们收到订单并且状态被更新到数据库 as400 发送平面文件确认并且状态被更新到数据库确认被转换为 x12 并且状态被更新到数据库 x12 确认被适当地路由并且状态被更新到数据库 确认被发送到如果 x12 包含无效数据，则将状态更新到数据库中可能的错误场景。
即使您将每个功能分解为自己的“功能”，您仍然会遇到日志记录问题，通知系统分析师应用程序引发异常或发生网络错误或找不到数据库等或业务组无法识别帐号的订单是遇到等。将其中任何一个添加到类中，作为方法、属性等似乎违反了单一责任原则。大约在那个时候事情开始旋转，我头晕，呼吸急促和心悸
因此，由于这对我来说非常混乱，以至于我什至不知道如何将其作为一个清晰的问题提出来，所以我将尝试这样总结。
你如何确定何时/何地以及如何分解这些东西并将它们分开？很容易说将它们分解成提供商业价值的最小部分，但是当你不能在没有许多其他部分的情况下拥有一个部分时，“真正”的答案是什么？所有这些都不适合一个粘性。
我愿意接受包括更多书籍、教程、视频在内的答案，但我认为是否有一些现实世界的应用程序可以解释这些类型的事情，这些事情遵守敏捷和 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
再次重复，用订单替换摘要。这就是我想出的。