This topic has been archived. It cannot be replied.
-
工作学习 / 学科技术讨论 / 关于unit test。 在大猫的帖子里， 几位大拿提到了unit test。 我有几个疑问： （1）app有多层，是每层的每个method都要unit test么？（2）需要对一个method写全部的test cases么？（3）如果database没有test data，需要在unit test里创建data么？如果（1）（2）（3）都做，那unit test本身的code会比原code大得多。维护起来也相当不容易。 不知道各位公司是如何handle的。谢谢。
-ejbeqhouse(执手，心安，吾家);
2014-1-9
{123}
(#8546436@0)
-
同问
-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)
-
谢谢几位的回复。我没对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(执手，心安，吾家);
2014-1-10
{2184}
(#8548261@0)
-
using framework 可以一定程度帮助 layers 之间的 decoupling，但一个 layer 内的 design 要想做到松耦合，需要 unit test*able* 来保证。另外，unit test*s* 有时*正*是验证需求的有效手段 ---- 尤其是需求变更时。不过这个话题比较大，很难一两句说清楚。尤其是我自己也不清楚 lol..
-xmlhttprequest(build5381);
2014-1-10
{26}
(#8548303@0)
-
老兄， 你们公司是按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,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?
-ejbeqhouse(执手，心安，吾家);
2014-1-21
{200}
(#8564780@0)
-
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.the unit test is useless only when the developer is trying to writing some useless code.
-ysysning(樱桃三果);
2014-1-21
{88}
(#8564874@0)
-
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)