单元测试（Unit Test, UT）是一个老生常谈的话题，在对这篇文章进行博客归类时，我还是将其归类为开发技术，尽管其带有测试两个字。如何做单元测试不是我这里想说的，而是业界对其认识的认识及重视是我想指出的。
对于单元测试存在两种不好的现象。第一种现象是对其不了解，或说了解只是在表面上（概念上）但并没有那种深入骨随的体会。只要学过或是看过软件工程的书，我想都会了解单元测试的概念，但说到体会，那可就不是每一个人都有的。
对于第二种现象是：太过于追求单元测试的，有的甚至要达到超过%90的代码覆盖率。近期，我看到了来自于Parasoft公司的一份报告，其中指出当代码的覆盖率超过大约%70时，付出的努力就太大了。这给我们什么想的启示呢？我能想到的是，我们不应当一味的追求高代码覆盖率，而是要进行一定的平衡，即做到保证一定的质量，又做到对于人力资源的合理使用。
站在程序员的角度来说，我想单元测试是会带来一定的工作量的，但好处也是显然的。好处体现在两方面：一是，所写的代码因为经过了单元测试，所以会比较的自信，而不是提心吊胆。反之，如果没有做过单元测试，而寄希望于测试人员来发现问题，那只会是忐忑不安。二是，有利于提高自己的声望。因为做了单元测试，所以设计出来的代码质量会相对的高，这无疑有利于提高自己的声望。就这两点来说，即使公司没有要求做单元测试，程序员自己也应当去做。
单元测试是一种提高软件质量非常有效的方法，但很重要的是我们要去实践和体会。在现代的敏捷软件开发方法论只，都非常强调单元测试的重要性。为什么呢？因为对于多次的迭×××发，我们需要通过测试来看是否新的迭代对于原有的功能是否有影响。还有就是，我们可能需要做重构，通过单元测试我们能发现重构后的代码是否对原有的功能进行了改变，而这是我们做重构后所不希望看到的。单元测试在现实实践中存在的一个不可忽视的问题是：测试用例的维护成本比较的高。往往对其维护的工作量并不比被测代码的开发量小，对于这一点我们需要有足够的认识。
我相信一旦将单元测试的方法运用到了日常开发中，你一定会喜欢上那种对于交付的代码很自信的那种感觉。
