TDD

上次是敏捷，这次说说TDD。

TDD现在的路子不对，讲的再怎么天花乱坠也还是单元测试的路子，实际上在业务系统的开发中作用未必如所说的那么明显，否则这么好的东西也不可能推广的这么困难。
业务系统的核心是数据，开发过程是数据驱动的，在一开始做开发设计的时候，用例和场景应建立在数据的基础之上，粒度在服务这一层就够了，然后逐步细化。单元测试这个层级粒度太小，做得再多，也不能保证一个完整业务跑的是不是正确。

那么什么才是正确的TDD呢？站的角度要高一点点，层次也要高一点点。
TDD不应该用现在这样的套路，而是应该基于功能，将测试数据和业务代码、测试代码分开，在项目的一开始就由业务顾问负责，组织设计、开发人员等等等等一起来设计、完善测试场景和测试数据，并且随时和业务客户来审核验证。
测试场景和测试数据是TDD的关键，而不是写多少的测试代码。

你说的不是TDD.你说的是做测试。你的主张是以服务层的集成测试来验证业务系统的正确性。

TDD这块我确实没有什么实践，从内心里我很排斥教科书的这种做法，我觉得如果这么去做，是自欺欺人，因为测试用例和测试数据的设计，谁来做，怎么做，怎么展开？Kent所说的，实际上还是站在开发人员的角度，只不过把单元测试的做法做了修正而已。

我想说的是要把测试数据做为核心来关注，不管粒度多细，现在各种介绍都围绕着代码展开，这个容易使人误解。

稍微大一点的业务系统，一个业务流程的处理，涉及的层面很多，只谈代码开发时的粒度太小的测试我觉得意义不大。

举个例子，销售订单的排序和资源匹配，一个流程就会涉及到周度、产能、产品、地域、供应商和经销商的各种规则，首先要基于主数据和业务数据进的测试用例设计和数据规划，代码开发人员是无法做到的。TDD我的理解是测试驱动，但不是单元测试来驱动。
测试用例的设计谁来做？各个角色在开发过程中如何来做测试用例？怎么才能容易操作，并且能够有效的进行业务验证，这些是我想说的。

再提一次“敏捷”，实际上还是代码开发人员想通过技术手段，代替业务分析、功能测试、发布等角色的工作，因此基于这个思路的开发方法，也就局限在开发这个层次，小项目可以，大一点的就很难去做。

我一直很好奇，为什么人们能对自己“没有什么实践”的东西有那么多“觉得”
嗯，勇气可嘉，虽然在论坛说说话其实也用不着什么勇气

要这么说就没劲了。
这么多年一直在项目一线，见过的门派多了。各家招式不一样，不会打还不能评价？

不过，我还是真的好奇，真正的TDD怎么做？

评论一下当然可以，问题是没有实践过的东西，只靠想当然，往往会出偏差的。比如说，你一直谈的都是系统测试，而不是TDD。TDD关注的是简单的设计，高内聚，低耦合的代码，而不是测试结果的正确性。至于说，TDD过程中的大量的单元测试，那只是额外的好处。它们可以减低重构时带来的风险，但它们不是为了测试系统正确性的，它们也不可能起到这个作用。如果说要测试系统正确性，当然要做集成测试，功能测试等等，当然有可能需要专门的人力在项目的不同阶段，设计/组织数据，安排测试。这和你说的并不矛盾，可惜你的题目是TDD， 而不是系统测试。

也许可以换个角度来想：是哪些人在推广tdd，以及他们为什么要推广tdd。

另外，我的经验是，任何一个需要花费1人周以上精力来解决的bug，统统不是tdd能够发现或者预防的。

frostred ：“TDD关注的是简单的设计，高内聚，低耦合的代码，而不是测试结果的正确性。”
这个我不是很理解，如果关注点是设计，而不是正确性，那么这个TDD的方向是不是偏了。

另外认为我说的是系统测试，不是TDD，这个我承认，不过这就是我想说的，TDD的层次是不是太低了，测试驱动开发，应该贯穿整个项目，而不是说在这个阶段用，另外一个阶段就是系统测试或者什么测试。保持测试工作连贯和完整的，是测试数据的设计，应该是整个项目团队共同关注的，而不是写测试代码，我更关注用例数据的覆盖率，而不是写了多少的测试代码，覆盖了多少，很多用例数据程序员他自己憋死也做不出。

TDD是一种开发的方法，其实很多人把它想的太复杂了。TDD只是要让开发人员更聚焦到开发的目标而不是其他地方。以前好像有人举国一个例子，比如要砌墙，首先掉一根垂线，这样才能保证不要砌斜了。每放一块砖头时都要保证不歪，才不会推到重来。

我自己见过太多软件开发到推到重来的例子，好多人总是强调软件和其他工作不同。但是根据我的经验，很多人在确定需求的情况都没有做到第一次就开发好，导致了非常多的由于自己开发原因的返工，浪费了大量的时间，还总是再找更复杂的原因。

其实很简单。TDD就是面对现在确定的需要，每一步都做对，活在当下，简单轻松！

如果觉得复杂，那就是纠缠了太多自己没确定的东西，作为程序员，只能对确定的东西编码，否则就是错了方向。。

没错，TDD是低层次的东西。它关注的是class/method这一层次的设计和实现。这有什么不对吗？你为什么觉得它的方向偏了呢？你又有什么其它方法可以保证代码的质量吗？

当然，我们开发软件，最终的目的是要一个可以正确运行的系统。代码的质量好，并不能证明它就一定正确。但它正确的可能性更大一些，而且即使不正确，好的代码修改起来也更容易一些。

其实敏捷的核心就是人和代码 - 通过程序员写高质量的代码来完成系统的构建。而不是开发前海量的设计/文档，开发后海量的测试来完成。敏捷的过程不是不重视设计和测试，它其实更重视，但它是在开发的过程中来完成，而且其中相当大的一部分是由程序员来完成的。