在新公司引入敏捷开发。我写unit test，下属写商业逻辑，可行吗？

补充一下楼上我的回帖，兼回复楼上两位朋友：

因为 test case 是控制系统设计、进度、以及质量的重要保障，所以我觉得，如果公司无法（或者不愿意）让每个程序员都为自己的代码自觉自愿写测试的话，由比较资深的 leader 来写比较合适。这也是我作为一个 leader 的一种负责任的表现。

而且作为 leader，编写 test case 事实上是一种亲自 control 开发的手段。

我也承认，由 leader 一个人来编写所有 unit test 是不太现实的。所以，可能会有一些变通的方法，比如拉人来帮忙，重点为关键逻辑写测试，等等。

leader把input和output定好，让程序员自己去测试不是更好吗？

lz还是先树立起自己的威信，显示出你的“两把刷子”再说。个人认为开发人员自己写测试，自己写实现，这样才有意思……你倒是可以先拉某个资深的人员或者某个心腹和你一起TDD，然后再推广到全部队伍。刚开始，人际关系还是要搞搞的……

领导要学会抓住主要矛盾，优先解决最重要且最急迫的问题。敏捷实践很重要，但对于一个从未实施过的公司而言，却并不那么急迫。再次建议你暂时搁下pair programming、TDD等等实践的愿望，先用低成本的方式让公司认识你，认可你。

btw：
如果你是项目的leader，如果你手下达到5-7个人甚至更多，你会发现根本没有时间去进行具体的业务逻辑编码（哪怕是几个用来驱动开发的test）。而且就算真要实施敏捷，你反而更应该做个coach，去协调、去组织。自己写unit test，更多也只是局部的，示例性的。

重要的是立住脚跟，先了解，再说变化的问题。

综合楼上各位的良言建议，我已经决定先保持低调，见机行事。

其实最终目的还是为了把事情做好。敏捷只是一种手段，一种我最熟悉的手段。

谢谢各位！我还有大约两个月才会进入新公司。顺便提一下，新公司不大，但是专门为银行、大企业开发应用系统，所以前景不错。到时候我有任何心得体会，会来跟大家共享的~~

如果你有一定的决定权， 可以定一些条例， 比如test code covery如果少于60%， 当然不光是交付给测试之前， 而是每一天都得达到。
我现在就这么干， 我的老板不应该干涉我的一些小组规定。
至于TDD， 等大家熟悉了unit testing， 知道了好处， 就很容易应用了。

人少，时间少，我现在遇到的也是这样忙乱的情况，不过我还是准备在下个project来写test，觉得现在因素越复杂，越应该注意“当下”

不要为了TDD而TDD。慢慢培养团队，需要大家对单元测试，相关工具都有深入的了解和掌握，等到了一定的程度，TDD是一个水到渠成的事情。
不论什么手段，最终目的是提供开发效率和质量。否则，仅仅为了追求测试覆盖率，不论上司还是下属都不会喜欢。

同意，TDD的test case包含多重含义，而定义接口仅仅只是其中一个部分，最重要的就是TDD的过程是一个重构的过程，在这个重构的过程中，unit test本身也是要经常修改的
这个不断重构的过程是一个紧密的持续性步骤，你把它分开两个人做，这就不是TDD了