很多开发人员，特别是小公司的开发人员，基本上从来不用单元测试，认为直接开发既快又好，还要做单元测试浪费时间和精力。但大公司相反，比较看重单元测试。因为有单元测试的代码，相对稳定可靠，而且如果开发人员习惯了以测试为驱动的开发，也会觉得这样的方式很不错。
以测试为驱动的开发模式是：开发之前，先想好要做什么，然后把对外的接口设计好，就可以先写单元测试的代码。之后再进行实际代码的开发，开发完成之后，再跑一遍之前写的单元测试，如果失败则调试，直到最终成功，会让开发人员特有成就感。
单元测试也特别适合于敏捷开发，开发新的功能以后，你不知道会不会对以前已经稳定的功能产生影响。当然你可以手工测试一下，但一次两次手工测试没问题，多了就会发现还是单元测试好，自动跑一遍就行，更符合程序员善于使用工具的优秀品质。
单元测试的工具，Android上使用junit加上ant脚本配合，ios上使用ocunit或者ghunit。虽然工具不同，但思想类似。
当然，并不是所有项目都一定要做单元测试最好。本人以前的项目，有用单元测试的，也有不用的，这里总结一下使用单元测试的2个原则。
1. 项目的规模原则。 如果是小项目，开发完就扔给客户，后期基本不用维护。那就偏向于直接开发，极快又好，你做得单元测试再多客户也看不见，做的快还能被客户夸。如果是大项目，你做第n个模块的时候，第1个模块的细节已经忘得差不多了，那这时候有单元测试可以帮助你确认前面模块的可靠性。
2. 因人而异原则。每个人的开发水平和性格不一样，有些人天性谨慎，开发的代码bug比较少，有些人比较粗放，bug就相对比较多。有了bug就需要测试和调试，当测试和调试的时间大于开发的时间时，建议下个项目使用单元测试模式开发。单元测试可以尽早让你发现代码中的问题，bug越早发现越容易解决。
