android单元测试好处

        许多开发者都有个习惯，经常不乐意去写个简单的单元测试程序来验证本身的代码。对本身的程序一直很是有自信，或存在侥幸心理每次运行经过后就直接扔给测试组测试了。然而每次测试组的BUG提交过来后就会发现本身的程序还存在许多没有想到的漏洞。可是每次修改好BUG之后仍是怀着侥幸心理，认为此次不会有bug了。而后又一次自信地提交，结果又败了。由于这样反复几回后。开发者花在找BUG和修复BUG的这些时间加起来已经比他开发这个模块花的时间还要多了。虽然项目经理已经预留了修改BUG和单元测试的时间。可是开发者却习惯性地在写好代码后就认为任务完成了。而后等问题出来了bug改了不少次仍是修复不了的时候才和项目经理说“我碰到预想不到的问题，可能要延期发布个人代码“。若是这个项目不可延期，痛苦的加班就没法避免了。

        为何有这么多的BUG开发者却没发现呢。其实开发者是人又不是机器。人非圣贤孰能无过。BUG是不可避免的，只是每次在修复一个BUG以前基本上没法知道这个BUG是哪段代码引发。每次定位BUG可能会耗去你一个小时仍是一天，这还要取决于你的水平了。可是若是你的每段核心程序都有单元测试代码。你将不须要靠你的经验去判断或猜想BUG是由哪段程序引发。你只要运行你的单元测试方法。经过简单判断测试方法的结果就能够轻松定位BUG了。因此从表面上看，为每一个单元程序都编写测试代码彷佛是增长了工做量，可是其实这些代码不只为你织起了一张保护网，并且还能够帮助你快速定位错误从而使你大大减小修复BUG的时间。并且这还有利你的身体健康，你将不会由于找不出BUG而痛苦不已，也将不用废寝忘食地加班了。并且项目的进度也将尽在掌握。

        其实单元测试不只能保证项目进度还能优化你的设计。有些开发者会说，写单元测试代码太费劲了，比写业务代码还麻烦。但是若是强迫开发者必须写单元测试代码的时候。聪明且又想‘偷懒’的开发人员为了未来能够更方便地编写测试代码。惟一的办法就是经过优化设计，尽量得将业务代码设计成更容易测试的代码。慢慢地开发者就会发现。本身设计的程序耦合度也愈来愈低。每一个单元程序的输入输出，业务内容和异常状况都会尽量变得简单。最后发现本身的编程习惯和设计能力也愈来愈老练了。

        其实容易测试的代码基本上能够和设计良好的代码划等号。由于一个单元测试用例其实就是一个单元的最先用户。容易使用显然意味着良好的设计。

        有着良好设计的项目一直是很注重代码重用的。代码重用的好处在这里就很少说了。可是要作到代码重用首先要保证被重用的单元程序必须是个很是优秀的程序，除了良好的设计，还要有详细的文档。另外最重要的实际上是单元测试代码。不知道你们有没有这样的经历？当你们不清楚一个API 函数如何使用而去寻找文档的帮助时，每每会跳过大段的英文说明而去直接看文档中提供的样例程序，而后在本身的程序中依葫芦画瓢调用这个函数。那么，您有没有意识到，被重用的代码若是有了单元测试代码。你的测试代码就能够成为这个函数最好的API 了。

        单元测试代码还能够经过简单的事务回滚功能在生产环境上作基于真实数据的测试而不用担忧会产生没必要要的数据。利用这样的测试代码咱们能够在发布程序后check 刚才的发布是否成功。以往发布的时候咱们常常会碰到一种比较尴尬的状况，当咱们将程序发布到正式环境上后，咱们每一个人内心一直仍是有点后顾之忧。由于咱们不能在正式环境上运行咱们的程序，只能被动地等待客户操做事后才知道发布的程序是否正常。这种状况让咱们很是被动，若是运气好可能不出什么问题，但是一旦客户在正式环境上发现报了个系统异常之类的错误或者出现错误数据，那就后果很严重了，这将影响到产品的声誉，显然这样也是很没面子事。若是咱们运行过单元测试代码，万一有问题咱们就能够主动的发现而且修改后从新发布。而其有时候就算有问题也多是一些比较低级的错误，或者多是发布问题形成。基本上很快就能解决掉！这样咱们不就高枕无忧了吗！

        不少研究结果代表，bug发现的越晚，修改它所须要的成本就越高，所以从成本角度来看，应该尽量早地查找和修改bug。或许有人会有异议？程序员把bug全找出来了，测试组干吗？其实测试组进行的是集成测试，这样的测试没法全面的考虑到每一个单元被调用时用的各类输入参数。就像一辆汽车，对每一个零件进行测试是必须的。对组装好的汽车进行测试是没法代替每一个零件的单独测试。或许对组装好的汽车进行测试能够发现某些零部件的问题。可是这个时候发现了问题就须要把汽车拆了换零件再装上。形成的成本可想而知。

转自：http://blog.csdn.net/u013104413/article/details/46333959