我有一个项目，其中大部分挑战是确保软件能够正确处理多个外部系统输出的纯文本文件。
管理层决定引入敏捷和 TDD 作为一种特殊的实现方式。
我发现从平面文件模拟输入没有意义，因为要解决的主要问题是完全正确地处理这些特定文件。
例如如果外部系统中的输出发生变化，则单元测试必须失败。
对从文件中抽象出来的代码进行单元测试几乎没有意义，并且创造的业务价值也很少（因为抽象的代码需要很长时间才能被抽象出来，实际上会产生一百行方法）。
只是想重申一下 - 挑战在于密切关注能够处理平面文件的软件，而 TDD 是要使其随时可验证。
会有什么建议？如何组织、定义和实施？
【问题讨论】：
在您的测试项目中包含示例文件，并使用这些文件进行测试。我倾向于将文件构建到测试程序集中并使用Assembly.GetManifestResourceStream 将其传递到代码中。在 API 中使用 Stream 或 TextReader 还意味着您可以使用 MemoryStream 或 StringReader 对测试代码本身中的数据进行非常小的测试。 （除非您需要担心检测编码，否则使用TextReader 可能比Stream 更合适。）
您可以使用StringReader 完成全部，但根据我的经验，如果您最终得到几行测试数据，它可能会变得相当混乱 - 单独的文件可以更容易地查看数据参与。
请注意，此不检查外部系统的输出是否未更改 - 正如 Pontus 所说，这将涉及系统/集成测试。但是，根据我的经验，您不想大部分在该级别进行测试。您应该混合不同级别的测试，但测试级别越高，运行所需的时间可能越长 - 设置起来可能就越困难。
您可能想要只测试外部系统的测试：有一段您希望从外部系统接收的样本数据，并有一个单元测试您的代码测试它的行为是否适当，以及一个“外部”测试调用外部系统并检查它们是否生成了准确的文件。这样一来，您就可以非常快速地判断故障是由于您的代码更改还是外部系统更改造成的。
【讨论】：
这听起来根本不像测试驱动开发或单元测试：您所描述的是外部系统的集成监控和/或system testing。您是在描述生产环境还是开发环境场景？如果文本文件发生变化，谁应该适应（您的消费者或生产系统）？
无论您做什么，请确保您有一个明确定义的合同，指定形成系统与外部系统接口的文本文件的格式和内容。如果可能，在生产环境中实施监控功能，如果源系统偏离合同，则会触发警告。
【讨论】：
平面文件的格式有规范吗？
如果是这样，您应该包含具有规范每个功能的示例文件，并为每个功能编写测试。
如果平面文件不符合规范，您就不能真正对它们执行 TDD - 您可能总是有一个新文件，其中包含未知内容。在这种情况下，您必须编写自己的规范（基于观察/研究）和针对该规范的 TDD。但是您仍然会对破坏您的代码的未知数据持开放态度。
道德？确保您至少有一份工作实践规范。
【讨论】：
从 .NET 的角度来看，平面文件本质上是字符串，所以我会围绕测试输入和输出字符串来设计我的大部分 API。
如果这些字符串太大，您可以将它们嵌入到单独的文件中，但最好的测试实践是将每个测试用例减少到重现/执行某个功能所需的最低限度。
【讨论】：