标签归档:单元测试

单元测试的一些体会

以前发布开源项目时被国外的网友一阵鄙视,之后在自己的一些小项目中陆陆续续的有写一些单元测试。你一旦真正接受单元测试,并实行起来还是很容易体会到单元测试的优点的。只是尽管单元测试有很多优点,在国内的环境下写单元测试的公司依旧不多。
单元测试的好不是立竿见影,需要时间的累计。在最求“速成”的环境下,单元测试没法推行也是显而易见的。
单元测试的问题

  • 单元测试并是立即见效的
    单元测试代码的书写也需要花费一定的时间,有时还需要不少时间。如只是从一次测试的效果来看单元测试多半是不划算的。单元测试解决的是之后代码改动之后再测试的时间。如果时间进度紧张,即使知道单元测试的好处也难有心去写。毕竟要先解决燃眉之急,更何况某些代码的生命周期很短,还不足以让单元测试发挥价值。
  • 单元测试的基础测试数据需要积累
    一些复杂的业务系统业务数据之间的逻辑关系会比较复杂。比如你需要有基础的客户数据、员工数据后才可进行合同创建等功能的测试。如果没有前期测试数据的积累,你要直接给合同模块写单元测试。想到要将员工、客户等数据补上,立马就退缩了。(注:其实手动测试也要将员工、客户先创建好,只是因为之前手动测试时相关数据已创建好)

如何开始

  • 在一些小项目中先用,真正体会一下单元测试的优点。
  • 从项目的一开始就使用单元测试。单元测试的书写和项目的书写一样,都是一个循序渐进的过程。
  • 只写一些必要的单元测试,不要最求大而全。即使手动测试你也不可能测试到所有小概率情况,所以可以只写一些最必要的单元测试,让单元测试代码发挥最大价值。