关于单元测试的一些看法 单元测试方法
从参加责任以来，参加了大大小小好几个项目了。对于项目中间的单元测试这一项，有一些想法，不吐不快。主要萦绕以下几个方面来说一说。(大家多多批评。)
1、对于一个项目，应该怎样划分在项目中需要测试的类和方式?
举个例子，一个基于被封装后的struts和EJB项目，哪些需要测试?在我看来，大而全是没有必要的。
个人认为，Action的单元测试属于对照没有用处的一个。因为在画面疏通的过程中，负担者对Action的测试会更加的仔细一些，基本上能够替代非常麻烦的Action单元测试。同时对于Form的测试在没有特殊的方式追加的状态下，也能够省略掉。
然后是Dao层的测试是需要做的，但是针对非框架组成部分的成员来说，测试SQL语句应该就足够了。CMP以及共通Dao的相关测试应该由框架来保证。
然后是service层的测试，用来做框架内部调用的代码的测试能够主动地无视掉，由框架开发者做出足够的测试就能够了。只针对业务逻辑的相关方式进行测试。在这里特别提一提设计上的一个问题。如果有通用的业务逻辑处理的话，建议直接应用工具类的形式来提供，而不要应用父类方式然后子类继承的方式，非常的不利于单元测试。(有不赞成见的能够批评指正。)
2、由谁来完成测试类?
我对照倾向于测试和功能代码的负担者不要是一个人。并且写测试的人要比写代码的人更加的熟悉详细设计。写测试和代码的人不一定是详细设计者，写代码的人能够看着详细设计写代码，不一定要非常的熟悉设计者的思路，完成详细设计的功能就能够了(当然，这个是相对的)。但是写测试的人却要清楚的知道每一步发生了什么，输入了什么样的对象，得到了什么样的对象，中间会有什么样的处理。
首先，测试的责任量一点也不小，相对不是捎带手就能做了的。基本上大一点的业务出现变更的时候，原先的对于该项逻辑的单元测试代码返工量是会对照大的。如果想要做好修复BUG或者是业务变更后的单元测试，消费的时间比修复BUG和业务变更的时间长很多。对于这个说法，我不知道其他人是否也是这样认为的?当然，在项目组长给你足够的时间的状态下，这个问题不是问题。
其次，当测试和功能代码的负担者来到之后，在项目里面，对于同一块业务，就有了至少两个人熟悉，不会出现只有一个人很清楚，其他人都不清楚的难堪形势。
第三，旁观者清的道理。写测试的和写功能代码的人互相都会有想不全面的中心，有一定的互补性。这样的测试，对照能够测试出代码中的冗余代码。
3、 在责任分配中，测试代码做成需要的时间和功能代码做成需要的时间比例多少是相宜的?
个人认为测试和功能代码的时间配比成2：1是一点也不过头的。在大的业务逻辑里面，测试数据的准备需要花很长的时间。
基本上我现在接触到的项目没有一个符合TDD的要求。有了解TDD的前辈请对我前面的观点进行无情的批评和打击，谢谢。
文章来源于领测软件测试网 https://www.ltesting.net/
