TDD指导方针认为从大范围开始还是从基础开始？

Question

按照TDD指南，我应该写第一个测试吗？对整个系统或最小的核心方法进行测试？

示例：项目应读取CSV并将其转换为XML。我的第一个测试应该是：

1. 采取一个CSV（输入）和相应的XML（预期），并检查是否应用程序正确执行转换（Assert.AreEqual（预计实际））？取一个CSV（输入）和相应的内存表示（预期）并检查它是否正确解析（Assert.AreEqual（expected，actual））？

第二个选项代表了用于实现整个目标，这是由第一选项所表示的方法之一。

Answer 1

你必须首先了解大局，但一旦你有了这个想法 - 从小处着手。决定你需要做的第一件事（小）。所以，举个例子，假设你想要一个给定一行输入的方法，以字符串形式返回一个单独值的集合。我要写的第一个测试会得到一串值：“1,2,3”，并期望一串字符串{“1”，“2”，“3”}。我会写更多的测试来改变不同值的数量和类型。为一个空字符串添加一个测试，等等。显然，我不知道你的确切期望是什么，所以只要将上述视为一种可能的方式，而不是做你想做的事情的方式。

我会慢慢建立功能，想到最终结果，让测试驱动应用程序的整体设计。如果你开始做大，我认为你不会在TDD方面取得成功，因为你必须在一步之内从无到有完成功能的飞跃。 TDD正朝着最终目标迈进一小步，让设计和代码随着您的发展而不断增长。

Answer 2

无论哪种情况都更容易。有时候，最好从顶层开始，当你可以嘲笑低层。在其他时候，最好从低水平开始并从那里上升。

我认为我经常从靠近顶端（例如UI模型）开始，特别是如果我没有清晰的底层应该是什么样子。但是，当我清楚地了解整体架构并且系统很大时，我可能会从较低级别的组件开始，我知道这将是需要的。

在这个特定的例子中，“一个项目应该读取一个CSV并将其转换为XML”，我会开始测试，而不是将空的CSV文件（实际上只是一个内存字符串）转换为一个空的列表内存中的表示。一次执行一次转换有利于分离责任，并且您将更好地知道转换中哪些方面存在缺陷。

这应该是微不足道的测试，以获得一个良好的开端。之后，您可以编写一个转换一行一列CSV文件的测试。根据它如何继续发展 - 如果证明自上而下过于困难 - 那么您可能会决定自下而上构建一些较小的部分，或者模拟一些较低级别的组件。