PDF《1. 介绍》

5 你应该知道的单元测试 是你开始自发性的完善测试,并开始尝试各种场景下测试用例的写法,你越来越了解它,最终,你们终于能愉快的在一起 了. 说完了动机的故事,我们再谈谈单元测试它本身所具有的价值,虽说付出并不一定需要得到回报,但对任何人都毫无价值的 事情,我们还是要坚决不做的. 这一点是毋庸质疑的,测试所存在的最主要价值就是帮我们解决错误,单元测试也是这样.当我们在对自己的代码进行测试 时,能很容易的就排除掉一些非常低级的错误,起码我们能够保证,在一些正常的情况下,代码是可以正常工作的. 当经历的语言和平台越来越多,很多平台相关的特性有时候并不是靠感觉就能拿得准的,比如你并不清楚 NSString 对象 的 equalTo 和 equalToString 这两个方法执行效果是否相同,那么你就有必要对使用到的代码进行测试去验证下,避免出现人 为意识造成的低级Bug. 可以说,在开发中我们有大部分的时间可能都是出于调试状态,减少调试时间,自然也就提高了产出率,而单元测试是否能 提高产出率一直也是有点争议,不过它的确能够有效的减少调试时间. 在一个应用中,并不是所有需要调试的代码都在程序的入口点,所以,当我们需要调试时,会花费一些额外的时间来触发调 试的代码.单元测试就能很好的解决这个问题,我们针对需要调试的代码,构建相关测试上下文,配合IDE,能方便快速的 进行反复模拟、测试. 很多书上都会说,代码就是最好的文档(当然是写得比较好的代码),注释需要能够精简,否则大片的注释会影响阅读.这 点我是非常赞同的,而单元测试,作为代码的一等公民,我觉得它能更好的描述代码的行为.在撰写单元测试时,我们基本 上都是假定某个方法,在某个特定的环境中,能够有预期的表现.如果这样的测试足够完善,那么,当我们去看别人测试 时,就能很清楚他提供的方法是为了适应怎样的场景,能够更好的理解设计者的意图. 当一个项目中单元测试的覆盖率很可观,后期在对代码进行修改时,能够很容易就知道是否破坏了老的业务逻辑,这样大大 的降低了回归出错的可能性.当我们从测试那获得一个Bug时,可以通过测试用例去还原,当我们这个测试通过后,这个Bug 也就解决了,而这个Bug Fix的测试用例也保证了以后这个Bug不会再次复现. 这会是一个很好的良性循环,我们的代码会越来越健壮,而我们可以把心思放在更多更有意义的事情上,比如重构.有了单 元测试的保障,我们可以比较大胆的进行重构设计,当然,在重构时单元测试也会成为一种负担,我们可能需要同时重构单 元测试,不过,相比于可靠性,这种负担还是非常值得去承受的. 测试驱动设计,这在敏捷开发中是非常火热的名词,但我自身并不认为在一个较大型的项目中,能够完全按照这样的方式来 驱动.虽然如此,但测试从一定的程度上能够改善设计,比如为了让一些类的某些行为中的细节得到充分测试(心里不再惴 惴不安),我们就必须要对这些行为进行细分,于是我们开始提取方法,构建测试用例.这样,我们方法的行为会越来越单 一,而良好的类设计中,正是需要这样的方法设计. 单元测试的价值所在 减少低级错误 减少调试时间 描述代码行为 可维护性增强 改善设计 测试用例的三步曲 iOS程序员