同大家一样, 我也是个java码农, 在默默努力着. 做开发也有2年+了, 从来没有用过单元测试, 
现在的开发模式就是拿到一个需求从头到尾都是一个人完成, 从Action, 业务逻辑, 数据访问, 到页面都是一个人开发, 需要测试的时候直接从页面发送一个请求到后台debug. 
是不是不同的人开发不同的模块, 这样才用到单元测试呢.
单元测试Java

解决方案 »

  1.   

    单元测试的优点  1. 帮助开发人员编写代码,提升质量、减少bug。如果大家分析一下我们bug原因的构成,我想有会有一部分bug的原因是开发人员在编写工作代码的时候没有考虑到某些case或者边际条件。造成这种问题的原因很多,其中很重要的一个原因是我们对工作代码所要完成的功能思考不足,而编写单元测试,特别是先写单元测试再写工作代码就可以帮助开发人员思考编写的代码到底要实现哪些功能。例如实现一个简单的用户注册功能的业务类方法,用单元测试再写工作代码的方式来工作的话  开发人员就会先考虑各种场景相关,例如正常注册、用户名重复、没有满足必要的填写内容......等等,之后就会编写相关的测试用例
    双击代码全选1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
     
    public Class UserSerivceTest(){
    public userRegister_Ok(){
    ......
    }
    public userRegister_nameDuplicated(){
    ......
    }
    public userRegister_emailEmpty(){
    ......
    }
    }
     
      编写单元测试代码的过程就是促使开发人员思考工作代码实现内容和逻辑的过程,之后实现工作代码的时候,开发人员思路会更清晰,实现代码的质量也会有相应的提升。  2. 提升反馈速度,减少重复工作,提高开发效率。开发人员实现某个功能或者修补了某个bug,如果有相应的单元测试支持的话,开发人员可以马上通过运行单元测试来验证之前完成的代码是否正确,而不需要反复通过发布war包、启动jboss、通过浏览器输入数据等繁琐的步骤来验证所完成的功能。用单元测试代码来验证代码和通过发布应用以人工的方式来验证代码这两者的效率差很多,看到很多开发人员每天要反复执行N次发布脚本(antx之类的工具)真是痛苦。  3. 保证你最后的代码修改不会破坏之前代码的功能。项目越做越大,代码越来越多,特别涉及到一些公用接口之类的代码或是底层的基础库,谁也不敢保证这次修改的代码不会破坏之前的功能,所以与此相关的需求会被搁置或推迟,由于不敢改进代码,代码也变得越来越难以维护,质量也越来越差。而单元测试就是解决这种问题的很好方法(不敢说最好的)。由于代码的历史功能都有相应的单元测试保证,修改了某些代码以后,通过运行相关的单元测试就可以验证出新调整的功能是否有影响到之前的功能。当然要实现到这种程度需要很大的付出,不但要能够达到比较高的测试覆盖率,而且单元测试代码的编写质量也要有保证。  4. 让代码维护更容易。由于给代码写很多单元测试,相当于给代码加上了规格说明书,开发人员通过读单元测试代码也能够帮助开发人员理解现有代码。很有opensource的项目都有相当量的单元测试代码,通过读这些测试代码会有助于理解生产源代码。  5. 有助于改进代码质量和设计。除了那些大拿们编写的代码,我相信很多易于维护、设计良好的代码都是通过不断的重构才得到的。虽然说单元测试本身不能直接改进生产代码的质量,但它为生产代码提供了“安全网”,让开发人员可以勇敢地改进代码,从而让代码的clean和beautiful不再是梦想。  单元测试的缺点  1. 单元测试的学习成本比较高。编写单元测试涉及的技术很多,如果只是单纯的使用Junit或是TestNG这样的基础单元测试框架往往很难应对各种复杂的单元测试情况,所以势必要借助很多第三方的框架和技术(easymock,jmock,dbunit等等),这些框架和技术的学习还是会增加学习的成本和难度。  2. 编写单元测试会增加程序员工作量。单元测试跟生产代码是一样的,并不会应为是用来测试的就有所不同,开发人员同样要面对测试代码的编写、维护等工作,也同样要面对避免重复代码等一系列问题,能否写出好的测试代码还是取决于开发人员的设计和编码能力。  3. 推广和运用单元测试需要比较大的投入。只有在每个开发人员都编写了足够的、质量好的单元测试代码,大家才能真正享受到单元测试带给我们的好处。在达到这种层度以前,还需要不少实现和资源的投入。  总结  虽然单元测试也有一些缺点和负面的效应,但跟单元测试的优点比较起来,为了克服和解决这些缺点所在的付出是值得的。
      

  2.   

        从字面上就能了解他的意思了,我的理解是:单元测试,就是对每一个单元进行单独的测试,要知道很多时候做项目都是一个团队一起合作开发的,通过分层开发思想以达到开发效率上的要求,单元测试就是要求每个人将他自己所负责的部分做好,这样才有利于团队整合代码,当然了,他同时也可以缩小程序的错误率,降低程序员查找bug时的范围。其实,不管你说几个人开发项目,都建议你用单元测试,只要你的代码层次分得好,单元测试绝对可以减少你很多麻烦事(如果你已经牛到代码可以一次成型的话就另当别论了)。
      

  3.   

    单元测试能覆盖更广的业务场景,而且能更关注于某一特定业务逻辑,一般单元测试仅需对service层。
      

  4.   

    单元测试是软件质量的第一道保障,因为是开发人员负责的,对代码逻辑熟悉,偏重于白盒测试。一个测试充分的单元测试,能够极大的保证软件质量。单元测试可以自己测试自己的模块,也可以开发人员交叉测试;可以使用JUnit测试,也可以模仿黑盒,使用专门测试工具测试。
      

  5.   

    我们写完业务层都会用junit测试的啊,调用的板块太多了,必须测试。
    例如:action只是负责传值辅助判断,但是页面每次重复填值事件很繁琐的事情,
    测试总是又重复,这时候我就用junit了,把所有要的值set好,剩下就是debug了。