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

多谢！我会仔细思考这个问题的。

或许楼上有人说的 结对编程 是个可能的解决方案。但要在新公司实施结对编程，难度太高了。老板绝不可能容忍程序员数目除以二的！嘿嘿，肉食者B啊~~~

这当然是最实干的做法。不过，目前我暂时还没有进入新公司，所以很想先看看其他人的经验。

unit test 和 商业逻辑 分开来写，到底行不行？？

楼上有的兄弟说可以，但更多的兄弟指出问题~~~ 唉，困惑ing...

等你到了新公司，也许真正要考虑的就是不是这些了
而是要考虑怎么团结好这个团队。 先把你的团队管理好了 让他们能够接受你 尊重你 拥护你 然后在tdd 敏捷。
就是说先让他们接受你的人 再接受你的思想，如果上来就给他们套tdd 敏捷。。。
路漫漫其修远兮 吾将上下而求索

这样分开的话，也就蜕化成了代码级的白盒测试，而失去了测试驱动的驱动含义

可以先通过一个模块来实践一下，过程中，估计一个模块还来不及完成就会暴露出问题，然后再来调整，只要有那个方向和意识，逐渐引入逐渐实施，一步到位的实施是有很多条件的

这种方式肯定是值得怀疑的，建议通过逐渐的培训和交流建立测试驱动的共识为最好

同意
TDD不是那个样子。

个人认为在一个新的环境马上要采用这个方法，还是会有难度的，因为你首先面临的是那里的开发人员是否能够信任你的问题，如果处理不好关系，你布置的任务，即使想法很好，也可能很难都倒实施（可能是大公司里面会碰到多一些）。

我还没有做过TDD，不知道现在是不是大多数公司都用了，我现在的公司里没有用，都是边写代码边写测试，最后交付的时候连同测试代码一同提交。这里也想请教一下楼主

1) 在原先的公司里面测试和代码是一个人写的还是分开不同的人写的，如何分开，是team leader写unit test，然后开发的人完成代吗? 写测试的人和写代码的沟通会产生问题吗? 设计上的问题以谁为准?

2)  如果team leader们都把class的接口都定义出来了，那么下面开发的人是不是轻松了点，还有就是team leader会有这么多时间去写这些class设计吗，我个人觉得设计的时间会占用比较多一些。

很有道理。可能我有些太操之过急了。

在讨论中逐渐理顺了我自己的思路。的确，我计划中的东东算不上真正的 TDD，只能是个以保证产品质量位目的的折衷。

唉，敏捷惯了，要退回去不容易啊。

1）原先（也就是目前）公司里面，测试和商业逻辑都是每个程序员各写各的，每个人都必须保证自己的商业逻辑可以通过自己写的测试。但是我们实行了 review 的政策，就是 team lead 有责任保证程序员的代码（包括测试和商业逻辑）质量。

2）正如楼上有人指出来，设计要细致到class的接口（也就是说，每个方法都要决定）是很难做到的。我们目前也是这样，系统设计一般都在class之间的关系这个级别，很少有真正深入到class内部，去定义每一个方法的签名。

假如设计真能细致到class内部，我觉得，测试和商业逻辑 这两种代码分开来写可行性会高些。