来源：51Testing软件测试网

        我曾经是一个不测试主义者，因为我看不到测试的价值。然后，我试了一段时间，变得对它深信不疑。我收集了一些经验，当然还远远不够。这篇文章总结了一些我知道的以及我认为我知道的内容。
        “我不总测试我的代码，但是当我测试的时候，感觉更好。”—— 我
        这是怎么一回事呢？
        这，全是因为代码：
        本文主要关于单元测试，而不是集成测试或端至端的测试，但在某些方面也可用于其他测试。在实践中，测试很少是单一的或非此即彼的，并且这也不是目的。
        单元测试成本低廉，因此应该成为测试工作中极大的组成部分。编写和运行单元测试都很便宜。因为它只查看代码的特定部分。集成测试则相反，它们包含的代码更大。
        为什么这很重要？
        测试可帮助你对你的代码放心。对一个稍复杂的问题写一个解决方案，然后手动测试，你只需要这么做就可以了。有着一定经验的你当然可以自信地发布代码，但是结果却往往是抛弃了发现错误的首次机会。
        测试能让你体验你的代码中在极端的条件下是什么样的。要是传递的数字是负数，会怎么样，在我们总是假定数值为正的情况下？要是传递的根本就不是数字，会怎么样？
        “每个人都会写出 bug，我们都写过 bug。因此，这不是“你能正确地编写代码或一次性写出正确代码？”的问题，我们都写过不正确的代码。这就是我们所做的一切，我们写的都是不正确的代码。”——Joe Eames《JavaScript. Air 004》
        编码是辛苦，我们都应该承认这一点。其中的主要原因之一就是，你需要测试代码，以获得它能如期表现的信心，不管是什么代码。
        不相信？这里给出了一些附加参数：
        测试过的代码更好
        许多人会告诉你，代码测试会导致更好的代码质量。这在使用单元测试，并且至少在测试驱动开发上有所行动，即使这些行动甚为草率时，尤其如此。原因如下：
        如果你的代码难以测试，那么可能是你代码没有写好。好代码的定义是什么，这是一个大问题，但这里要强调的一句话是一个很好的经验法则，也是大多数人所赞同的，那就是，好的代码会分离关注点。有经验的程序员限制功能体以便于只做一件逻辑上的事情就是这个原因。
        目标对齐
        代码很难测试可能要么是因为有太多的事情要继续，要么是因为有太多的依赖（或两者皆有）。考虑将此视为协调利益的一个问题：在编写未经测试的代码时，在速度（或懒惰）和关注点分离之间存在着利益冲突，并且短期内你的代码是如何被组织的并没有那么重要。当代码必须测试时，你的目标更一致，因为对于写得好的代码，更易于写测试！
        像消费者一样思考
        当你首次编写测试时，你首先要设计代码的 API。测试让你进入代码消费模式，在这种模式下，你的代码需要面对其他东西的接口。设计 API，而不那么关注内部运作将导致一个更佳的 API 设计，这会导致模块的更易消耗，从而促进项目代码的更干净。
        灵感突现
        测试会让你灵机一现。通常情况下，因为它迫使你去思考边缘情况——零值，10 ^ 12，null 或 undefined。这使得你有机会来思考。去反省，以及了解在陌生的环境下会发生什么。仅仅是思考这些的过程，或代码将面对的其他情况，都经常会让你意识到代码可以简化（以及代码需要如何保护自我）。
        这些灵感突现的时刻也可能来自特别令人沮丧的情况之一：当你的代码和测试不一致的时候。你正处于不知道哪个才正确的两难境地。如果你碰到这种情况，那么设计可能有问题，或者你的前提假设发生了变化。把它看成是一个好兆头！你的代码将会更满意。
        测试可以说明代码做了什么
        没有人喜欢写文档，但当你继承（从一年前的自己，或其他人）或接口的模块文档齐全的时候，绝对是好的。测试可以成为这样一种途径，并且还有一个额外的好处是：测试用实际行动证实代码。就如同极佳的科学教师，他们不只是用嘴巴告诉你，氢气易燃，而是充了一个氢气球，让它升到天花板上，然后在棍子上放一根点燃的火柴靠近气球（这是我五年级时特别难忘的时刻之一）。
        你知道所有 bug 的共同点吗？那就是它们经过了所有的测试。所以，当你找到一个 bug 的时候，就等于知道测试哪里还需要改进。
        测试可以使得更容易地加入项目，因为它们揭示了代码实际上应该做什么。它们告诉你设计决策，以及初始的开发人员心里在想什么。
        不要担心，去重构吧
        也曾看到过乌七八糟的代码，但不敢去清理干净？我在这种情况下要做的首件事是创建测试来找出代码要做什么。测试可以锁定功能，用一种很好的方式，使得我们能够专注于“大扫除”，而不是担心破坏什么东西。
        我见过一些糟糕到让人不知道它们是做什么的代码片段。同样的，人人避之唯恐不及，不但要担心会破坏预期的功能，而且还要担心破坏 bug。我认为基于过去的I/ O 的大型测试集是非常值得的投资。
        有趣的是，担心和快乐的心情是成反比的。总之是一种此消彼长的状态。
        自信地创造价值和正确的产品
        正确的代码比不正确的代码更有价值。一切帮助你的代码比以前更正确的东西都值得看一看，就这么简单。发布正确的代码随着时间的推移会构建起信任，而信任是一笔宝贵的财富。
        鱼与熊掌不可得兼
        这里有一个技巧：不要在试图解决问题的同时，设计一个很好的解决方案。来自于 Ian Cooper 关于 TDD 演讲中的秘诀是：
        编写红色测试。解个问题，尽快让它变绿。设计一个很好的解决方案，重构成你为之骄傲的一个东西。
        这里要掌握的一个重要内容是，在你的大脑中要分离关注点。不要试图同时完成步骤 2 和步骤3。编程的主要限制之一是你的大脑一次能思考多少，并且在你敲代码时，你需要思考得越少，你写的代码越好。
        在解决问题时，不要去想代码实际上应该如何。复制粘贴代码，写低效的循环，重复内容，不论是什么只要能尽快让测试变绿就去做。然后再考虑如何改进。
        分离关注点是首先要测试的原因之一，这种方法有助于实践中行为。当你不择手段地想要快速达成一个解决方案时，你不必去考虑它看上去怎么样或者运行起来快不快。当你进行到完善设计和改善解决方案的时候，你就不必担心解决方法行不通了。

王萍老师	小文老师

《中华考试网软件测试培训》
《教育软件测试培训频道》
《软件测试培训课程——深圳川石》
《深圳川石软件性能测试培训》
《深圳川石企业性能测试(PL&LR)提升班》
《持续集成自动化测试UFT Selenium提升班》
《深圳源昊宝安软件测试培训班》
《深圳凌岳软件自动化测试培训班》
《深圳博睿软件安全测试培训》
《深圳达内软件测试培训学校》