实践TDD的点滴——如何写好TODO

    我觉得TDD入手最重要的一个环节的就是对TODO的分解，每条TODO最终都能分析到一定的可测试的粒度，否则很难转化成测试代码。在TDD的几本书中，似乎TODO是轻而易举的事，但往往在具体项目中却让人不知如何下手。书上的例子大多都是一些纯逻辑的问题，而具体的项目往往都是数据库，UI，网络同逻辑混杂一起。而此也造成了大多TDD推行的流产。我是从事网络多媒体相关开发，在项目团队中推行TDD，发现几乎所有的开发人员TODO都不知道如何细化分解，因此我在这里通过一个具体的例子把我的分解列出来。

项目描述：
    这是一个监控相关的项目。有多个现场，每个现场都有多个摄像头，客户端可以监控各个现场，同一个现场也可以从各个角度监控。客户端可以同时有多个视频窗口，每个现场都可以独立选择绑定的现场和绑定的摄像机位。

业务需求：
   

用户可以选择不同的摄像机位观看现场。

系统需求分解：
   

a)用户从下拉条选择要查看的视频机位，选择后在对应的窗口播放视频。

b)由于可能有多个窗口在看视频，本窗口选择的视频可能另一个窗口已经在播放了，因此确保同一个机位视频只订阅一次。

c)记得要清除原有订阅的视频。

d)如果视频所在的服务器不同需要建立新的连接。如果另的窗口的视频源同一个服务地址，则只用一个连接。

个人观点：系统需求分解就是将业务需求结合开发环境、架构、性能、对象生命期管理的进一步分解。

TODO：

1. （不测）切换下拉事件：如果没有机位没变化则不改变当前状态

2. （不测）切换下拉事件：如果机位发生变化，取消窗口同旧的视频流的绑定

3. （不测）切换下拉事件：如果机位发生变化，建立窗口同新的视频流的绑定

4. （要测）建立窗口同视频机位的绑定：如果该机位视频已经有其它的窗口订阅了，那么无需重新订阅，直接使用原有订阅，添加该视频订阅合约同窗口的关系。

5. （要测）建立窗口同视频机位的绑定：如果该机位视频还未订阅过，那么进行订阅。

6. （要测）订阅机位视频：创建或取得同该视频源的访问代理对象，订阅机位所在通道的视频流。

7. （要测）创建或取得同该视频源的访问代理对象：如果视频源所在的代理对象已经存在，直接返回

8. （要测）创建或取得同该视频源的访问代理对象：如果视频源所在的代理对象不存在，则创建，并取得同该服务器的连接，将该代理对象放入连接中。

9. （要测）取得同该服务器的连接：如果连接存在，直接返回

10. （要测）取得同该服务器的连接：如果连接不存在，则创建一个新的连接

11. （要测）取消窗口同旧的视频流的绑定：从订阅的节点中，移除本窗口

12. （要测）取消窗口同旧的视频流的绑定：如果订阅节点中的所有绑定窗口都清空了，则真正向视频源取消对应通道视频流的订阅。并清除视频源的访问代理。

13. （要测）清除视频源的访问代理：如果代理所在的连接器没有任何其它代理，则断开并清除连接

个人观点：由于1、2、3涉及到MFC的窗口控件调用，测试麻烦，固不进行测试。

个人观点：由于涉及的问题较复杂，因此TODO也是采用逐层挖掘的方式，如：
    切换下拉事件
        建立窗口同视频机位的绑定
            如果该机位视频已经有其它的窗口订阅了
            如果该机位视频还未订阅过
                订阅机位视频
                    创建或取得同该视频源的访问代理对象
                        如果视频源所在的代理对象已经存在
                        如果视频源所在的代理对象不存在
        取消窗口同旧的视频流的绑定
            从订阅的节点中，移除本窗口
            如果订阅节点中的所有绑定窗口都清空了
                清除视频源的访问代理

个人观点：由于TDD是驱动设计，而不是保障接口的有效性测试，而此可以去测试一些private的函数。如何测private，不同语言不同，我是用c++，采用friend方式就可以。

    以上是我的一些思路，纯粹是个人在项目中的摸索，还请大家共同指教。另外我觉得不同的软件开发，会有一些各自适用的经验，大家也可以一起贴出来交流学习。

我就是依据这个分解来开发的，不过TODO分解到这个程度，入手代码一样有些举动为艰的感觉。是否分解的粒度不够，还是分解的方向不正确。还期望前辈们指点。

和你观点类似，粒度越细，代码越繁杂。

不过，根据个人的开发经验，有一些“显而易见”的需求TODO测试就没有必要。

其实没必要做这么多前提工作，要先动手后完善，否则同样会掉入过度设计的泥潭中。

之所以分解那么细，是希望能达到可测的级别，然后再开始TDD。另外我想说的是需求和实现是相对的，最高层的业务需求的实现就是系统功能分析，系统功能分析又是具体类设计的需求，上层功能类相对它是实现。上层功能类的进一步分解也是体现一种设计实现方法。以此类推，每一层次都自己要实现的功能，通过TDD去实现代码。

我只是想找从一份业务需求到进入TDD节奏的路径。如果这里有问题，也是在于通往TDD的这条路径或者理解TDD是否合理的问题，至于是否过渡设计，我想TDD有优点就是可以防止过渡设计。

个人认为测试是建立在需求上面的，TDD可以帮助发现过度设计，不认为能够防止，毕竟需求是置顶向下。

我觉得 测
足够了

todo list不是仅在task开发之前分解的一份静态list，而是在TDD过程中动态细化的工具。上面的todo不是我最开始的todo，而是开发完成后总的todo list。
TDD的原则是每写一段代码之前都先写一个失败的测试代码进而driven design。开发的过程需要不停的细化问题并最终成为可测的功能，这会体现在todo的列表上。过程中todo list是动态维护的，当一个问题包含了几个逻辑时进一步分解添加todo到list中，直到可以通过一两个测试来驱动完成功能。

恩。。。如果要花大量时间思考如何写 test case的话，也很让纠结啊，如果后期需求变更，这些测试代码又会增加成本

现在客户需求总是在变的，我有个项目一个模块重写了4次、、、、、、、