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，而是需要实现复杂的逻辑。
通往优雅代码的路径就是不断地重构。
类名，方法名，变量名能不能准确地表达意图？ 让人一看就知道是怎么回事？
方法是不是太长， 各种逻辑交织在一起， 能不能提取出新的方法？
类的职责是不是划分得不好，导致有些类过分臃肿？
这个模块如何进行扩展？ 对外暴露的接口用起来怎么样？
......
强烈建议每个程序员写完代码以后，再审视一下，看看有没有上面的问题。
如果有，那还愣着干什么， 赶紧改吧！ 可是改动代码破坏了功能怎么办？ 要是有单元测试就不怕了。 兜了一圈，又回到了单元测试！
重构要求在不破坏原有代码的功能的情况下对代码进行改动，让它变得更好， 没有单元测试是很难的。
对于重构的具体技巧，我就不罗嗦了， Martin Fowler已经总结了一本书：
总之，单元测试和重构是程序员的两项基本技能，他们和编程语言无关，如果你没有掌握的话，很难说是一个合格的程序员。
【本文为51CTO专栏作者“刘欣”的原创稿件，转载请通过作者微信公众号coderising获取授权】
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
1024·人与机器共同进化
东西文库 / 译言·东西文库／电子工业出版社 / 2013-12-20 / 55元
《1024》：国内第一本专注于科技文化的mook。 本期创刊号将目光定焦在“人与机器”这个超热点领域。 如果把机器获得思维能力看作是一种进化， 那人类具备不朽之躯同样也是一种进化。 这是一个野心勃勃但又充满不确定性的未来。 在我们一厢情愿地猜测机器将在不远的将来赶超自己而惶惶不可终日时，人类其实还有一个机会——变得更像机器。这并非科幻小说，而是正在发生的现实。人类创造......一起来看看 《1024·人与机器共同进化》 这本书的介绍吧!
