这篇文章想和大家讨论的是关于单元测试的一些想法，各位看官有什么自己的看法，也欢迎一起讨论。因为TDD关于测试先行的争议较多，这里并不局限说单元测试必须先行。
　　1、为什么我们需要单元测试？
　　Quora上有这么一个问题：In Test Driven Development， how do unit tests help drive good design?
　　Ken Beck是这么回答的：
　　TDD doesn't drive good design. TDD gives you immediate feedback about what is likely to be bad design. If a test is hard to write， if a test is non-deterministic， if a test is slow， then something is wrong with the design. When I'm not ready to make good design decisions， I still don't end up with a good design， but I certainly know I have room for improvement.
　　虽然我并不是TDD的拥趸，有时候也比较质疑TDD先行测试的理念，但对于单元测试可以改善代码质量，还是持肯定的态度。原本不易于测试的代码变得更容易测试的同时，提升了程序员的模块设计能力，降低了代码的耦合度。这个事情本身也很好理解，花更多的时间去思考你的代码，当然质量提升了。所以越是菜鸟，越是应该写好单元测试。
　　单元测试的好处很多，列几个比较重要的：
　　-很容易定位Bug，它好像在你的程序中打了无数的断点。
　　-很费时间。不过，我们知道，后续改Bug更费时间。
　　-可能使覆盖率达到的测试。
　　2、为什么有很多人不写单元测试呢？
　　前面说了很多好处，那为什么现实中有很多人不写单元测试呢？我想主要有以下几个原因:
　　-我们并没有在开始的时候养成这个习惯，大学老师可没告诉我们写完代码要写单元测试。
　　-没写单元测试的后果是过段时间才会体现的。
　　-没写单元测试的后果并不一定有本人承担，很多时候坑害的是队友。
　　-很难评价单元测试的效果。
　　总的来说，单元测试并不是必需品。
　　3、怎样写单元测试？
　　既然说了这么多单元测试的好处，那么单元测试有哪些需要注意的地方。这里引用《Junit Recipes》作者J. B. Rainsberger的意见：
　　1.When writing a test， start with what you want to check， then write just enough code to compute that result.
　　2.Don't perform multiple actions in the same test. Test one action at a time.
　　3.Don't assume that you have to group tests for the same function or object together.
　　4.Don't test the platform; worry about your stuff.
　　4、我们真的需要单元测试吗？
　　之前写了一堆单元测试的好处，现在问这个问题，到底是闹哪样！
　　1.必须承认的事情是单元测试会花费程序员大量的时间，虽然在完成了UT框架和一些基础架构之后，接下来的UT会简单的多，但仍然不能否认UT会消耗程序员很多时间。
　　2.在初期设计不明确的情况下，代码的改进同样需要我们修改UT。
　　3.十分紧急的小型项目可以考虑不写单元测试。
　　不管单元测试会给我们带来多少好处，只是整个项目开发周期中的一环，必须服从整个项目的安排。项目经理需要协调各方面的资源，从而选择合适的开发模式。花多少精力或者花不花精力在单元测试上会是权衡各种利弊综合考量后的结果。
　　5、结语
　　单元测试可以帮助你更准确全面的理解整个代码逻辑，一定程度上的提升代码的设计。但这里也要提醒大家，不要对UT有盲目的依赖心理。改了程序，跑一遍UT发现没问题，以为代码完全正确了。即使完全覆盖也是一样，因为覆盖率只是说明代码被碰到了，代码是怎么被碰到的并没有办法判断。UT也不可能测试所有的情况。所以在编写代码的时候首先依靠的还是严密的逻辑推理，而不是通过UT反证代码的正确性。
　　另一方面，项目经理们在考虑是否需要做UT，花多少时间做UT， UT覆盖率要到多少等问题时，也要先看看表，数数人头，摸摸自己的钱包。