遵循TDD指南时，我应该首先编写哪个测试？对整个系统或最小核心方法的测试？
示例：项目应读取CSV并将其转换为XML。我的第一个测试应该是：
获取CSV（输入）和相应的XML（预期）并检查应用程序是否正确转换（Assert.AreEqual（expected，actual））？
获取CSV（输入）和相应的内存表示（预期）并检查它是否被正确解析（Assert.AreEqual（expected，actual））？
第二个选项代表用于实现整个目标的方法之一，由第一个选项表示。
答案 0 :(得分：6)
你必须首先了解大局，但一旦你有了这个想法 - 从小开始。决定你必须做的第一件事（小）是什么。因此，例如，假设您想要一个给出一行输入的方法，则将各个值的集合作为字符串返回。我要编写的第一个测试将采用一串值：“1,2,3”并期望一个字符串数组{“1”，“2”，“3”}。我会写更多测试来改变不同值的数量和类型。添加一个空字符串的测试等。显然，我不知道你的期望是什么，所以只考虑上面的一种可能的方式，而不是你想要的方式。
我会慢慢构建具有所需最终结果的功能，让测试驱动应用程序的整体设计。如果你开始大的话，我认为你不会成功使用TDD因为你必须在一步中从无到有跳到完整的功能。 TDD旨在为最终目标采取微小的渐进步骤，让设计和代码随着您的发展而增长。
答案 1 :(得分：3)
无论哪个更容易。当你可以嘲笑较低级别时，最好从顶级开始。在其他时候，最好从较低的水平开始并从那里上升。
我认为我经常从顶部开始（例如UI模型），特别是如果我没有清楚地了解较低级别应该是什么样的。但是当我清楚地了解整体架构并且系统很大时，我可能会从一个我知道需要的低级组件开始。
在这个特定的例子中，“一个项目应该读取一个CSV并将其转换为XML”，我将从一个测试开始，而不是将一个空的CSV文件（实际上只是一个内存中的字符串）转换为一个空的列表。 - 记忆表示。一次进行一次转换有利于分离责任，您将更好地了解转换的哪一侧是错误。
这应该是一个微不足道的测试，以获得一个良好的开端。之后，您可以编写一个测试，用于转换包含一行和一列的CSV文件。取决于它是如何进行的 - 如果它被证明太难以自上而下 - 那么你可能决定自下而上构建一些较小的部分，或模拟一些较低级别的组件。