今天你写了自动化测试吗

一艘货轮满载着货物从港口启航，向浩瀚的大海深处破水而去。海面平静，微微皱起波浪，从容而显得宽容。然而，货轮的步履却有些蹒跚，发动机“轰轰轰”地嘶吼着，不堪重负，却无法让船只游得更快，倒像是海水咬住了船底往下在拖曳。

“嘟——嘟——嘟”，突然警报声响起，甲板上变得喧闹起来，一个水手模样的年轻人声嘶力竭地呐喊：“船超重了，快快快……快卸货！”声音急迫，甚至能听到哭音。然后，又是一阵喧嚷，似乎是在争吵甚么，就看到一个胖胖的中年人冲了出来。看他那肥胖的体型，真难想到他的身手竟然如此敏捷，如海豹一般破开人群，两手挥舞，大声喊道：“怎么了？怎么了？”，他停下来，吼道：“我看哪个不长眼的家伙敢卸我的货！谁敢！”

船长走了过来，略带恭敬地对那中年人说道：“老板，你看，这船超载了，船身吃紧，已经发出超重警报了。倘若不减轻船的重量，这船开不了多久就得沉了啊！”

“他奶奶的，这船可真秀气啊！”中年人一边骂骂咧咧，却也知道形势紧迫，容不得自己不下决断。可是心里总存着侥幸心理，突然灵机一动，一把拉过船长，指着这艘货轮问道：“既然这船超重，那我问你，除了货物，这船上还有哪些东西占了船身的重量？”

船长一听，立刻明白老板心里的小九九，没好气地回道：“除了货物，占了这船重量的就还有人、淡水、食品，还有救生圈、救生衣、救生艇。老板你看那样不顺心，你就扔哪样吧！”

嘿，回到现实中来吧。回答问题：倘若你是老板，你会扔哪样呢？稍有理智的人，都不难做出正确的选择。——然而，为何在软件开发过程中，我却常常看到有人选择丢弃救生圈、救生衣、救生艇呢？哪怕它们的重量对于整艘船而言如同九牛一毛，却总有人存着侥幸，认为船就超了那么一点点，或许扔出几个救生圈，就能恢复重量到安全线；于是，货物得以幸存，可以避免不必要的损失了。

或许，我们没这么傻吧。那么，让我们想想。

假设将这航行比作是软件开发的过程，那么载货到达目的地，就是实现软件需求。只有交付了货物，才算是实现了价值。至于淡水、食品以及船只，就是开发的工具与环境，而救生圈、救生衣、救生艇，就是我们在开发过程中需要编写的自动化测试（单元测试、集成测试、验收测试等）。我们需要这些测试来随时检测开发功能是否有误，及时反馈，就像在航行过程中，若是有人溺水，可以用救生衣、救生圈挽回一条生命一般。

可一旦开发时间紧促，人手严重不足，进度压力山大时，我们想到了什么呢？对于我见过的多数软件团队而言，每当面临如此窘境时，首先想到的就是减少甚至不做自动化测试。有人认为自动化测试没有价值，浪费成本；有人认为自动化测试可以以后再补，先把功能完成再说；有人认为有了手动测试，就足以保障项目的质量……如此这般，自动化测试就这般被忽略了，沦落到随时可以抛弃的地位。

倘若软件开发就只有这一个阶段，没有需求变更，没有后续开发，没有软件维护。项目的代码库如树苗一般在阳光雨露下茁壮成长，没有大风狂吹，没有烈日暴晒，没有大雨倾盆，亦没有虫蚁啃啮，那自然由得它去。然而，现实世界哪有如此美好！

Michael Feather 将没有自动化测试的代码称为“遗留代码”，温伯格在《咨询的奥秘》中则认为应该将“维护”工作视为“设计”工作。自动化测试是修改的基础，重构的保障，设计的规约，演化的文档。它的重要性怎么强调都不过分，然而很可惜，在很多软件项目开发中，它甚至不如“鸡肋”的地位，说放弃就放弃了，在决定当时，毫不觉得可惜。至于以后的以后，不远的未来，谁还顾得上！！？债欠下了，什么时候偿还呢？——不知道！到了催债的那天，再想办法还债吧。

鸵鸟心态害死人啊！

扪心自问，我们经历过维护的苦楚吗？体验过修改代码的烦恼吗？修复过不胜其扰的缺陷吗？答案若是肯定，那么，如果老天再给你一次机会，把选择自动化测试的权利放在你面前，作为“曾经沧海难为水”的你，你会怎么选？——所以，我想问问程序员们：今天，你写自动化测试了吗？