Spring在“清算”EJB的时候,提出的一大罪状就是:强迫开发者继承它的类,依赖容器,难于单元测试。
Spring的解决之道就是POJO,摆脱容器的控制,可以独立创建和测试。即使是对SpringMVC这样重度依赖容器的框架,Spring也提供了不需要Tomcat/Jetty运行,就可以对代码进行单元测试的办法: Mock。
不仅仅是Spring, 你可以看看自己正在使用的语言和框架,是不是都有单元测试的支持?
Java就不用说了, Python 语言有unittest, Python写的Django框架也有django.test, Ruby 和Ruby on Rails 有TestUnit, MiniTest。 ReactJS 有 Enzyme, Vue.js 有vue-test-utils……
\
为什么这么多大牛都把单元测试加入到语言和框架中来呢?
答案很简单,单元测试实在太重要了。
单元测试对于程序员来说,就是一个防护网, 能让你有信心开发新的特性而不破坏现有的实现,与此同时,良好的单元测试,还能帮助别的程序员理解你的代码。
尤其是对于动态类型语言做的大型项目,没有单元测试,修改代码是一件“可怕”的事情。
一个代码单元(可能是一个类,或者是一组类) ,如果被充分地测试过,这个代码单元通常有这样的特点: 和别的模块耦合度低,是面向接口编程(只有这样才能实施Mock,才能测试),这样的代码就是好代码。
对于一个有追求的团队,对于一个想持续维护一个“正经”应用的团队,单元测试都是必备的。
同理,对于一个有追求的程序员,单元测试也是必备技能。
可能有些人会说,我们的项目很复杂,没有写单元测试,项目也运行得很好啊! 我想也许有这么几种可能:
可能做的是一锤子买卖。
项目中已经埋下了地雷,只是没有发现。
在测试阶段付出了巨大的代价,拼命加班,修改了无数的Bug。
当然,有些单元测试是不容易写的, 最难搞的就是遗留代码, 你得想办法解耦才行,这方面有人专门写了一本书,强烈推荐。
\
没有人一次就把代码写得既正确又优雅,如果你是这样的人,请告诉我,我得拜你为师。 当然,我说的不是入门的Hello World,而是需要实现复杂的逻辑。
通往优雅代码的路径就是不断地重构。
类名,方法名,变量名能不能准确地表达意图? 让人一看就知道是怎么回事?
方法是不是太长, 各种逻辑交织在一起, 能不能提取出新的方法?
类的职责是不是划分得不好,导致有些类过分臃肿?
这个模块如何进行扩展? 对外暴露的接口用起来怎么样?
……
强烈建议每个程序员写完代码以后,再审视一下,看看有没有上面的问题。
如果有,那还愣着干什么, 赶紧改吧! 可是改动代码破坏了功能怎么办? 要是有单元测试就不怕了。 兜了一圈,又回到了单元测试!
重构要求在不破坏原有代码的功能的情况下对代码进行改动,让它变得更好, 没有单元测试是很难的。