同大家一样, 我也是个java码农, 在默默努力着. 做开发也有2年+了, 从来没有用过单元测试,
现在的开发模式就是拿到一个需求从头到尾都是一个人完成, 从Action, 业务逻辑, 数据访问, 到页面都是一个人开发, 需要测试的时候直接从页面发送一个请求到后台debug.
是不是不同的人开发不同的模块, 这样才用到单元测试呢.
单元测试Java
现在的开发模式就是拿到一个需求从头到尾都是一个人完成, 从Action, 业务逻辑, 数据访问, 到页面都是一个人开发, 需要测试的时候直接从页面发送一个请求到后台debug.
是不是不同的人开发不同的模块, 这样才用到单元测试呢.
单元测试Java
双击代码全选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. 推广和运用单元测试需要比较大的投入。只有在每个开发人员都编写了足够的、质量好的单元测试代码,大家才能真正享受到单元测试带给我们的好处。在达到这种层度以前,还需要不少实现和资源的投入。 总结 虽然单元测试也有一些缺点和负面的效应,但跟单元测试的优点比较起来,为了克服和解决这些缺点所在的付出是值得的。
例如:action只是负责传值辅助判断,但是页面每次重复填值事件很繁琐的事情,
测试总是又重复,这时候我就用junit了,把所有要的值set好,剩下就是debug了。