现在很多公司都在抓质量，质量！质量！质量！为什么都在抓质量，在IT行业多元化复杂化的今天，也就意味着竞争会异常的激烈，那么作为互联网软件公司，怎么提升我们的竞争力？我们不是某些国企，不需要某些套路，我们的企业是否能生存，取决于我们的用户，抓住我们的用户，我们就能生存，怎么抓住我们的用户？那必须要获得用户的信任，让他们能放心的投资在我们身上，购买我们的产品。
抓住我们的用户，那么我们就需要提高我们的产品质量，这也是取得用户信任的关键步骤，那么我们是做软件的，就必须要提高我们的软件质量。针对软件质量可以从很多方面去提升，开发，测试，运维等等。开发里面又要分静态检查，白盒测试；测试里面又要分功能测试，性能测试等等，每个环节都有很多提高我们质量的方法，今天呢我只针对开发来讲怎么提高我们的代码质量，而且只针对白盒测试，也就是单元测试。
很多公司，下到开发，几乎人人鼓吹白盒测试有多好，对质量的杀伤力有多大，可是，能真正做起来单元测试的公司少之又少，小公司基本不愿意投入做单元测试的人力成本，大公司呢，说起来容易，个个开发几乎都是自己写完代码自己测试两次了事~那么我们到底有没有必要来做单元测试呢？我来说说我的观点，分别从时间和工作量来分析。
时间
即使你没有多少开发经验，你也应该能够想象，单元测试最大的问题，就是它需要花时间花精力去写，那么这个花费是否值得呢？这还是由你架构的目标决定的，或者你的需求决定的。如果系统是一次成型交付使用，此后几乎不会更改的，那么一次性的手工测试就够了；但如果你的系统是会被“千锤百炼”的不断折腾修改的，那么这个测试就是很有必要的。最简单的考虑：每一次更改，我都要手工测试一次；那还不会如我多花点时间，弄个“自动化”的东西出来。单元测试，其实就可以理解为一种自动化的测试工具。
但是“自动化”的理由还远远不够。因为你马上想到的，每一次需求变更代码调整，测试代码也得相应的改呀？没有测试代码，我就只需要改开发代码；现在有了单元测试，我还得再改测试代码。本来我只维护一套代码，现在我凭空增加了一套代码也需要维护，这不是增加了维护成本，不是和你“可维护性”的架构目标背道而驰了么？是一套代码好维护呢，还是两套代码更好维护？
这是一个非常好的问题，适用于很多情景（比如分层架构，你说分层解耦，实际上还不是一改就得从UI层改到数据库，每一层都得改？）。我能给出的回答大概有：
- 无论有无单元测试，开发代码进行修改之后，是不是都要进行测试？没有单元测试，并不代表你的代码就不需要测试了，只不过是你手工的去测试了一遍而已。切记：程序员的工作并不只是把代码写出来而已！
- 进行手工测试，和更改单元测试，两者的耗费比，会根据测试重用的次数而变化。一次手工测试可能需要5分钟跑完，更改单元测试代码可能需要20分钟，但如果这测试会跑100遍，单元测试完胜手工测试。你说，哪里哟？什么功能会改100遍？我没说你的功能会改100遍，我说的是测试会跑100遍。有区别么？
工作量
所以其实当对象间的关系变得越来越错综复杂，像一张密密麻麻的网一样之后，一个局部的改动就很有可能会触发极其复杂的连锁反应。所以为了保险起见，所有可能相关的组件都应该进行测试（所谓的“回归测试”）。这时候如果只有纯粹的手工测试，会面临两个问题：
- 难以确定测试的边界（那些部分可能会被影响），凭空想？手动代码走读？
- 极大的测试耗费。而且这种耗费是相当的无聊繁琐伤人心的——没人愿意做这种事。
测试只能告诉你出了bug，不能告诉你根源啊。没有单元测试，单步调试需要花更多的时间。这是系统本身的复杂性，或者代码组织的不合理造成的，不能归咎于单元测试。不还是有这么多开源代码都有详尽的单元测试么？他们是怎么做到的呢？在单元测试上的付出，最终一定会获得超值回报！想想没有单元测试的公司，那超级庞大的测试团队，或者四处冒烟的系统，你愿意走这么一条路么？
这样一种说法：可测试的代码不一定是好代码，但坏代码几乎是不可能被测试的。深度耦合的代码，写他们的单元测试，难于上青天；但反过来，我们可以以可测试为标准，不断的完善重构开发代码，只要这样坚持下来，最终代码的质量怎么都不会差到哪里去。
总结：所以，个人观点，对于某些关键功能和通用底层库，必须要做单元测试，如果真的要把产品所有的代码都做单元测试，其实是没有必要的，也不必要花这么多的财力人力。当然，通过做单元测试，不仅能提升公司产品的竞争力和稳定性，也可以提升开发人员的开发能力。
