3.3 写一个测试列表
在开发新功能之前先创建一个测试列表会很有帮助。测试列表由需求衍生而来。测试列表定义了你对将需要完成的功能的最好的理解。这个列表不需要很完美。它只是个临时的文档，可能只记在一张卡片上或者笔记本上。你也可以直接把它当做注释输入到测试文件中。随着每个测试的添加，对应的注释将被删除。
不要在写作这个列表上花太多时间，对于LED驱动程序来讲，花几分钟即可。我的初始测试列表如图3-1所示。
在我们开始之前，先列出我们都需要测试什么。
请当心在创建测试列表时的报酬递减（diminishing return）。一旦你写下几个测试，其他的会很容易想到。当进展很慢时，你可能已达到了报酬递减的边界，这可能就是一个停止工作在测试列表转而去测试驱动设计的好时机。在驱动设计的同时你会想到其他的测试。有时一个测试将来可能会被拆开。有些可能会被合并。这个列表的目的是确保你不会忘了做某些事。它就像是一个地图，你可以在努力让一个测试通过而深入其中之余重新找回原来的方向，它就是你的任务列表。
有些识别出来的测试可能还没有明确的产出。例如，你觉得驱动程序应该如何应对越界的参数？答案是不清楚。不过这没关系。在把代码拼在一起后你大概会对可能的选择更了解一些。有时更多的经验会帮助澄清问题，但有时它会引发新问题，一些不能马上解决的问题。
从下一节开始，你将会开始使用测试驱动开发。在此之前，我有个问题。是否有人告诉过你先把问题中最难的那部分解决掉，小问题自然会迎刃而解？至少我听到过，并且这看上去是个好建议。我将会彻底颠覆这个建议。
应该从能把工作向目标推进的很小或很简单的地方开始。这个过程中的每一步都是可验证的。产品代码的功能随着一次一个的测试而增加，朝着健壮的并且被很好测试过的解决方案前进。这为我们进行更复杂的测试打了基础。设想一下需要写的测试，并决定写出它们的顺序，这是一个随时间而增长的技能。
