更好的设计
　　当你为自己的代码写单元测试的时候，尤其是采用TDD的方式，你会很自觉地把每个类写的比较小，功能单一，这是软件设计里面很重要的SRP原则。此外，你能把每个功能职责分配的很清楚，而不是把一堆代码都塞到一个类里面（比如Activity）。你会不自觉的更偏向于采用组合，而不是继承的方式去写代码。这些都是很好的一些代码实践。
　　至于为什么TDD能够改善代码的设计，网上有很多的文章去分析和论证这个结论。我看到比较印象深刻的一句话是（具体在哪看的搜不出来了）：当你TDD的时候，你是从一开始，从一个代码的使用者，或者说维护者的角度，去写你的代码。这样写出来的代码，自然会有更好的设计。
　　更强的自信心
　　有单元测试来保证你的代码是对的，这对于你写代码、发布代码、重构都提供了信心保证，没有那么多的担心，从而工作起来也更快乐更开心。做人呐，重要的是开心。。。
　　没有时间写单元测试？
　　前面大概讲了讲我为什么要写单元测试，以及单元测试给我带来的好处，这些其实如果大家去google “why unit testing”，估计会得到类似的答案，然而依然会有很多人不写单元测试。如果问为什么的话，那么得到多的回答，估计是：没有时间。
　　那么，写单元测试真的需要很多时间吗？为什么多数真正写过单元测试的人会说，写单元测试可以节约时间呢？在这里，首先要承认两点。。。
　　1. 单元测试，的确是一门需要学习的技术。
　　不仅需要学习，而且你要学习的东西还真不少，你要学习JUnit的使用，你要学习Mokito的使用，Robolectric的使用，依赖注入的概念和使用等等等待。此外，在刚开始的时候，你的确也会遇到很多坑，现有代码的坑，Android的坑，Robolectric的坑等等。这个在安卓开发这边显得更是如此，因为Android开发环境是公认的不利用写单元测试的环境之一。你需要花一些时间去学习如何处理，或者是绕过这些坑。
　　2. 在一个现有的，没有单元测试的项目里面加入单元测试，会需要一段时间的调整。
　　一个有单元测试的项目，跟一个没有单元测试的项目相比，结构会有比较大的不同。因此刚开始，你会发现各种不顺利的情况，你需要去调整各部分的代码，让他们变的容易测试，这也是比较花时间的地方。
　　这种调整值得吗？我认为是值得的，因为容易测试的项目，往往意味着更灵活，更具备扩展性，这个前面已经提到过了。所以本身这件事情是一件值得做的事情，更何况，测试本身又是一件非常有价值的事情。
　　然而等跨过了这两道坎，单元测试还需要花很多时间吗？根据我自己的经验，我觉得其实不是这样的，因为等你熟悉了如何写单元测试以后，要对一个类、一个接口写单元测试，是很容易的一件事情。如果你发现一个类不好测，往往是因为这个类的设计是有问题的。此外，你可以慢慢的搭建自己的一套测试框架，简化一些常用的繁琐的写法，让写单元测试变得更简便快捷。再加上前面讲述的原因，总体来说，我觉得写单元测试非但不会需要跟多时间，反而会节约时间。
　　小结
　　这篇文章简单讲述了，为什么要写单元测试。其实，单元测试的必要性，看看那个知名的程序员必看书单知道了。在前20本中，所有5本讲述“如何写出更好的代码”的书，无一例外都强调单元测试的必要性。
　　· Code Complete
　　· The Pragmatic Programmer
　　· Refactoring: Improving the Design of Existing Code
　　· Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
　　· Working Effectively with Legacy Code by Michael C. Feathers
　　希望这篇文章，能让你多一点学习和实践单元测试的决心，因为这真的是非常值得拥有的一项技能，只是刚开始的时候，需要多一点点时间而已。