谢谢几位的回复。我没对TDD深入学习。大概看了网上说的，（1） do all test cases before implementation; (2) try 100% code coverage; (3) some people online suggest to test service layer but not dao layer; (4) 在wiki里也提到的Coupling的问题。我的还有些疑问：

ejbeqhouse(执手，心安，吾家)

本文发表在 rolia.net 枫下论坛（1） do all test cases before implementation;
作为consultant company而言，好像很难做到这点。BA gather the client's requirements, 然后我们implement。但这些requirements常常是不完善和不确定的，我们完成后，show给客户，客户修改要求，我们修改code，这是一个iteration的过程。我很难想象do all test cases before implementation。如果每次客户提出新的requirements或修改requirements，我们都先做all test cases再implementation，进度会严重拖慢，客户未必会高兴。

(2) try 100% code coverage;
我想这需要相当多的时间。test code所花的时间会超过implementation的时间。客户愿意pay么？比如我昨天重写了一个method based on the new requirements, 这个method本身就20-30行code，但它的test的cases有10多个，近300行。而以前的test code全部作废。这些时间到底值不值？

(3) some people online suggest to test service layer but not dao layer;
我承认绝大部分business logic应该放到service layer。但dao layer的query很多时候也不是简单的对一个entity的update/query/save。很多时候dao layer的query也有很多logic也很复杂。很多时候bug都是这些query产生的。要不要对dao layer的query做test呢？对我而言，很多时候， unit test是我debug DAO layer 的一个主要手段。

（4）关于Coupling的问题
我更倾向这是design的问题，而不能依靠TDD。解决Coupling，一般靠选取framework，比如用现在流行的spring 和spring.net等架构，基本上就解决了Coupling的问题。而且Coupling的问题主要是architect负责，而TDD是由developer的负责。好像应该各司其职吧。

我们现在开始要求完善test cases，并不是真正的TDD。一般都是developer完成implementation，然后给QA去test。当qa test时，我们做test cases，能完成多少test cases看情况而言。每次PM问我什么时候可以给QA做test，我告诉他implementation已经完成，正在做test cases，他就等不及了（因为QA， UAT无所事事，等做测试），让我直接deploy给QA和UAT。基本就完全违背了TDD的原则。

而且一个sprint一般都是3-4周，要等develope先做test cases，再implementation，然后给QA/UAT 测试，那一个sprint就做不了啥事了。

另外无论是先做test case还是先implementation，因为是同一个developer，大部分bug是由对requiremnet的描述或理解的偏差造成的，所以很多implementation的bug在test cases中一样存在。
并且test case完成后，很少去维护它，时间长了，基本就失去意义了。

很希望知道到底有没有公司是完全按TDD的模式来做开发的。谢谢。更多精彩文章及讨论，请光临枫下论坛 rolia.net

(#8548261@0)
Last Updated: 2014-1-10
This post has been archived. It cannot be replied.

同问 -tjhong(以后再说); 2014-1-9 (#8547306@0)

我觉得起码business logic layer需要写unit test。test code应该越简单越好。test code不应该从物理层获取test data。test data 应该就在 test code 中。要用好Mock class。我在网上看到有人还给test code写unit test。这个就超过我的想象之外了。。。 -minbin(光辉岁月); 2014-1-9 (#8547330@0)
按照Agile里的TDD，unit test的coverage几乎要100% -sallay(sallay); 2014-1-9 (#8547340@0)

个人愚见，TDD 的重点不是 100% code coverage 而是解耦 ---- 保证 100% unit testable... -xmlhttprequest(build5381); 2014-1-9 (#8547462@0)

using framework 可以一定程度帮助 layers 之间的 decoupling，但一个 layer 内的 design 要想做到松耦合，需要 unit test*able* 来保证。另外，unit test*s* 有时*正*是验证需求的有效手段 ---- 尤其是需求变更时。不过这个话题比较大，很难一两句说清楚。 -xmlhttprequest(build5381); 2014-1-10 {26} (#8548303@0)
尤其是我自己也不清楚 lol..

老兄，你们公司是按TDD模式做开发的么？我们公司有点画虎不成反类犬的味道。 -ejbeqhouse(执手，心安，吾家); 2014-1-10 (#8548318@0)

如果database没有test data，需要在unit test里创建data? ----> that is why you need mock database, or even you do not need a mock database, you just need mock the context to the method .... it is not one word to explain. -ysysning(樱桃三果); 2014-1-10 (#8548290@0)

没怎么用过mock，对我们而言好像有点难度，比如被测试的method用到的数据因为business logic的关系要涉及数十个tables的数据，用mock是不是工作量大了点？如果所有test做下来，基本上就是用mock创建整个database了。三果，你们是这样做的么？谢谢。 -ejbeqhouse(执手，心安，吾家); 2014-1-10 (#8548314@0)

很惭愧我也好几年没怎么写大段codes了，我的理解是unit test, 只是test one of the unit, 不是测试整体，如果说你的test需要跟那么多的context打交道，说明你不是在做unit test, 而是system intergartion test了。"unit"需要划分到最小，只测一个小的unit。 -ysysning(樱桃三果); 2014-1-21 (#8564579@0)

我们是对service层的method写test，这个层的method要完成一个transaction可能会调用很多DAO层method。要达到100%coverage，很有点痛苦。 -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564619@0)

从unit test的角度看，被测试的method应该首先分解成读写十几table数据的unit和对这些操作的unit，分别进行test。这就是为什么很多tier的application有DAO这一层的原因。当method分得越细，mock的代价就越小。测试得也越全面。 -geekcode(文心雕码); 2014-1-21 (#8564601@0)

按老兄的说法，是对DAO层做unit test. 但我看网上大部分人是说对service层做unit test呢？ -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564634@0)

No, the exact opposite. To test service method, you have to mock the DAO. And, you can only mock it after you have a separate DAO layer. -geekcode(文心雕码); 2014-1-21 (#8564798@0)

So you suggest 对DAO层做unit test but not service layer? -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564826@0)

No, I suggested how to unit test service layer. -geekcode(文心雕码); 2014-1-21 (#8564861@0)

I see. Thanks. -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564956@0)

:) -geekcode(文心雕码); 2014-1-21 (#8564959@0)

其实以前我看过国内的一点资料，也是对DAO层（hibernate）做unit test。我也比较理解。但前不久用google看了看，大部分人却建议对service层做unit test。但对service层做unit test好像难度不小。 -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564659@0)

all the same.... -ysysning(樱桃三果); 2014-1-21 (#8564665@0)

service 层有太多business logic，把DAO层的method组合起来的话，test case的量会大大增加。 -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564677@0)

when you test service layer method, why bother to call real DAO? just give it a fake/mock DAO context. -ysysning(樱桃三果); 2014-1-21 (#8564727@0)

Thanks. I got your idea a little bit. However even to use a fake/mock DAO context, to reach a 100% test coverage of one service method, -ejbeqhouse(执手，心安，吾家); 2014-1-21 {200} (#8564780@0)
we still need to consider all the combination of return values of those DAO methods called by this service method, even they are fake values. In your real life, is it true to reach 100% test coverage?

5 years ago , my team was asked to reach code coverage to 90%, if below that we have to stop writing new code to rise the rate to 90%. most time, we just wrting some useless test to fullfil this goal ;) -ysysning(樱桃三果); 2014-1-21 (#8564796@0)

Thanks， that is what I think, "we just wrting some useless test to fullfil this goal". It became "形式主义”。 -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564802@0)

no, actually, unit test is very useful. like my current project, if someone change the code, the unit test will failed if some function is changed, then we can find someone changed it by wrong way. -ysysning(樱桃三果); 2014-1-21 {88} (#8564874@0)
the unit test is useless only when the developer is trying to writing some useless code.

Maybe your project is very well organized. Hopefully I have some opportunity to learn from your project. -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564994@0)

That's why test coverage is a dangerous measure. It's worse than no tests in this case, as it gives you false confidence to break Prod code. -geekcode(文心雕码); 2014-1-21 (#8564871@0)

In my projects, our test code keeps increasing, but nobody maintains it. So it become a useless after business changed. -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564998@0)

Take a look at frameworks like Mockito. Do not create stub, only specify the return values you want for each test case. Pretty straight forward. -geekcode(文心雕码); 2014-1-21 (#8564806@0)

Thanks a lot. Will check it. -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564809@0)

if no mock, then the test coverage will not be good, actually no mock then no real test. -nextin(next car); 2014-1-21 (#8564562@0)

谢谢，看样我要好好看看mock了。 -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564622@0)

很希望各位大侠告知一下： In your real life, is it true to reach 100% test coverage for any service method? Thanks in advance。 -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564799@0)

if it is a start from scratch and OO app, I will say it is possible to do that, at least 90%. but if it is existing app, just start to test the most important one first , the one you do not have confidence. -ysysning(樱桃三果); 2014-1-21 (#8564813@0)

I see. For me, it is a little bit boring to write those test cases. I just do not like it. However it became part of job. Thanks for the suggestion. -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564816@0)

you will find pleasure later when you master that, actaully for a new project when you finished the unit test, you coding is almost done. -ysysning(樱桃三果); 2014-1-21 (#8564879@0)

I understand. But it requires the business requirements are very well defined before the coding. However it is not ture in the real world at most of time. -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564971@0)
As TDD asked, you even should write those test code before you implemente the methods. -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564977@0)

Feeling boring is an indicator that those test cases may not help improve test quality. In other words, those test cases might be boilerplate code just for the sake of test coverage. Then it is bad, as it costs your time as well as ones maintaining it. -geekcode(文心雕码); 2014-1-21 (#8564915@0)

Well said, cannot agree anymore. -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564973@0)

well, this creates job opportunity and positions. we are paid to do so, why complain? -ysysning(樱桃三果); 2014-1-21 (#8564980@0)

lol. More work load, more positions. Btw, how many percentage of the time you spent on those test cases when you were asked to reach 90% coverage? -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564985@0)

Test coverage should only be used to detect critical code which is missing test, but not a measure for success or test quality. At the end, test quality matters, not test coverage. -geekcode(文心雕码); 2014-1-21 (#8564884@0)

Yes, I agree. But some PM just want to reach the number, even how many lines of the code you have been typed. lol -ejbeqhouse(执手，心安，吾家); 2014-1-21 (#8564964@0)

@Florida

谢谢几位的回复。我没对TDD深入学习。大概看了网上说的，（1） do all test cases before implementation; (2) try 100% code coverage; (3) some people online suggest to test service layer but not dao layer; (4) 在wiki里也提到的Coupling的问题。我的还有些疑问：

Replies, comments and Discussions:

More Topics

@Florida

谢谢几位的回复。我没对TDD深入学习。 大概看了网上说的， （1） do all test cases before implementation; (2) try 100% code coverage; (3) some people online suggest to test service layer but not dao layer; (4) 在wiki里也提到的Coupling的问题。我的还有些疑问：

Replies, comments and Discussions:

More Topics

谢谢几位的回复。我没对TDD深入学习。大概看了网上说的，（1） do all test cases before implementation; (2) try 100% code coverage; (3) some people online suggest to test service layer but not dao layer; (4) 在wiki里也提到的Coupling的问题。我的还有些疑问：