单元测试 about plmcodetemplate HOT 6 OPEN

从来没有要求过开发人员写单元测试用例做单元测试代码，差距太大了。现在是小学水平，你要求的大学知识。

开发人员总有一种错觉，觉得做单元测试是开发的必备一个步骤。不敢水平高低，总觉得自己写的代码没有问题，能很容易测试，其实，在复杂的业务里面，能写出能做单元测试的代码，是相当困难的。所以基本上不考虑单元测试，只对部分没有任何业务的工具类之类或者一些业务比较独立的代码做做单元测试。
大部分普通开发人员，写出来的代码，输入输出乱七八糟，参数各种复杂类型，没有什么可读性、可维护性，更加别说写测试代码。连最简单的日志要求一下子不评审代码都做不到，还妄想做单元测试？
当然，对外当然说我们开发有完整的开发流程，有需求评审，概要设计，详细设计，代码review，单元测试等各种环节，但实际上很多业务代码根本不需要这么复杂的流程。大部分开发难的是在业务，而不是技术，实现功能用到的技术，说实话实在太简单了（绝大部分）。
当然，你脱离了初级开发人员之后，写得代码能看的下去了，可以写单元测试用例，这也是一种提高。

from plmcodetemplate.

那么,你们是有专职的测试人员么??
项目迭代的时候回归测试怎么做?
项目上线前的集成测试怎么做?
纯手测试?

from plmcodetemplate.

当然有，还不少。
主要是人工测试，有些接口会有自动化脚本。
曾经花了很大力气做页面自动化测试，但是难度比较大而且业务复杂变动比较大，这块没有继续下去。

from plmcodetemplate.

不太苟同，单元测试还是要的，而且单元测试不在于当前一次两次编写，而是长期积累过程，越积累到后面，越能发挥他的效益

from plmcodetemplate.

@hunkyeung 本工程比较简单，测试用例比较好写。已经补充测试用例，包括异常测试

from plmcodetemplate.

使用log4j的MDC打印用户名等额外信息这个对我很有帮助

单元测试感觉比较适合一些算法比较合适。
比如订单类;字段都五六十个，就不好写测试了

from plmcodetemplate.