<h2>我们为什么要写单元测试？</h2>    <p>“满足需求”是所有软件存在的必要条件，单元测试一定是为它服务的。从这一点出发，我们可以总结出写单元测试的两个动机： <strong>驱动（如：TDD）和验证功能实现。</strong> 另外，软件需求“易变”的特征决定了修改代码成为必然，在这种情况下，单元测试能保护已有的功能不被破坏。</p>    <h2>基于以上两点共识，我们看看传统的单元测试有什么特征？</h2>    <p>基于用例的测试（By Example）</p>    <p>单元测试最常见的套路就是Given、When、Then三部曲。</p>    <ul>     <li>Given：初始状态或前置条件</li>     <li>When：行为发生</li>     <li>Then：断言结果</li>    </ul>    <p>编写时，我们会精心准备（Given）一组输入数据，然后在调用行为后，断言返回的结果与预期相符。这种基于用例的测试方式在开发（包括TDD）过程中十分好用。因为它清晰地定义了输入输出，而且大部分情况下体量都很小、容易理解。</p>    <p>但这样的测试方式也有坏处。</p>    <ul>     <li>第一点在于测试的意图。用例太过具体，我们就很容易忽略自己的测试意图。 比如我曾经看过有人在写计算器kata程序的时候，将其中的一个测试命名为“return 3 when add 1 and 2”，这样的命名其实掩盖了测试用例背后的真实意图——传入两个整型参数，调用add方法之后得到的结果应该是两者之和。我们常说测试即文档，既然是文档就应该明确描述待测方法的行为，而不是陈述一个例子。</li>     <li>第二点在于测试完备性。因为省事省心并且回报率高，我们更乐于写happy path的代码。 尽管出于职业道德，我们也会找一个明显的异常路径进行测试，不过这还远远不够。</li>    </ul>    <p>为了辅助单元测试改善这两点。我这里介绍另一种测试方式——生成式测试（Generative Testing，也称Property-Based Testing）。这种测试方式会基于输入假设输出，并且生成许多可能的数据来验证假设的正确性。</p>    <h2>生成式测试</h2>    <p>对于第一个问题，我们换种思路思考一下。假设我们不写具体的测试用例，而是直接描述意图，那么问题也就迎刃而解了。想法很美好，但如何实践Given、When、Then呢？答案是让程序自动生成入参并验证结果。这也就引出“生成式测试”的概念——我们先声明传入数据可能的情况，然后使用生成器生成符合入参情况的数据，调用待测方法，最后进行验证。</p>    <h2>Given阶段</h2>    <p>Clojure 1.9（Alpha）新内置的Clojure.spec可以很轻松地做到这点：</p>    <pre>  ;; 定义输入参数的可能情况：两个整型参数  (s/def ::add-operators (s/cat :a int? :b int?))  ;; 尝试生成数据  (gen/generate (s/gen ::add-operators))  ;; 生成的数据  -> (1 -122)</pre>    <p>首先，我们尝试声明两个参数可能出现的情况或者称为规格（specification），即参数a和b都是整数。然后调用生成器产生一对整数。整个分析和构造的过程中，都没有涉及具体的数据，这样会强制我们揣摩输入数据可能的模样，而且也能避免测试意图被掩盖掉——正如前面所说，return 3 when add 1 and 2并不代表什么，return the sum of two integers才具有普遍意义。</p>    <h2>Then阶段</h2>    <p>数据是生成了，待测方法也可以调用，但是Then这个断言阶段又让人头疼了，因为我们根本没法预知生成的数据，也就无法知道正确的结果，怎么断言？</p>    <p>拿定义好的加法运算为例：</p>    <pre>  (defn add [a b]   (+ a b))</pre>    <p>我们尝试把断言改成一个全称命题： 任取两个整数a、b，a和b加起来的结果总是a、b之和。 借助test.check，我们在Clojure可以这样表达：</p>    <pre>  (def test-add  (prop/for-all [a (gen/int)                b (gen/int)]               (= (add a b) (+ a b))))</pre>    <p>不过，我们把add方法的实现(+ a b)写到了断言里，这几乎丧失了单元测试的基本意义。换一种断言方式，我们使用加法的逆运算进行描述： 任取两个整数，把a和b加起来的结果减去a总会得到b。</p>    <pre>  (def test-add  (prop/for-all [a (gen/int)              b (gen/int)]             (= (- (add a b) a) b))))</pre>    <p>我们通过程序陈述了一个已知的真命题。变换以后，就可以使用quick-check对多组生成的整数进行测试。</p>    <pre>  ;; 随机生成100组数据测试add方法  (tc/quick-check 100 test-add)      ;; 测试结果  -> {:result true, :num-tests 100, :seed 1477285296502}</pre>    <p>测试结果表明，刚才运行了100组测试，并且都通过了。理论上，程序可以生成无数的测试数据来验证add方法的正确性。即便不能穷尽，我们也获得一组统计上的数字，而不仅仅是几个纯手工挑选的用例。</p>    <p>至于第二个问题，首先得明确测试是无法做到完备的。很多指导方法保证使用较少的用例做到有效覆盖，比如：等价类、边界值、判定表、因果图、pairwise等等。但是在实际使用过程当中，依然存在问题。举个例子，假如我们有一个接收自然数并直接返回这个参数的方法identity-nat，那么对于输入参数而言，全体自然数都互为等价类，其中的一个有效等价类可以是自然数1；假定入参被限定在整数范围，我们很容易找到一个无效等价类，比如-1。 用Clojure测试代码表现出来：</p>    <pre>  (deftest test-with-identity-nat   (testing "identity of natural integers"     (is (= 1 (identity-nat 1))))   (testing "throw exception for non-natural integers"  (is (thrown? RuntimeException (identity-nat -1)))))</pre>    <p>不过如果有人修改了方法identity-nat的实现，单独处理入参为0的情况，这个测试还是能够照常通过。也就是说，实现发生改变，基于等价类的测试有可能起不到防护作用。当然你完全可以反驳：规则改变导致等价类也需要重新定义。道理确实如此，但是反过来想想，我们写测试的目的不正是构建一张安全网吗？我们信任测试能在代码变动时给予警告，但此处它失信了，这就尴尬了。</p>    <p>如果使用生成式测试，我们规定：</p>    <p>任取一个自然数a，在其上调用identity-nat的结果总是返回a。</p>    <pre>  (def test-identity-nat  (prop/for-all [a (s/gen nat-int?)]             (= a (identity-nat a))))      (tc/quick-check 100 test-identity-nat)      -> {:result false,   :seed 1477362396044,   :failing-size 0,   :num-tests 1,   :fail [0],   :shrunk {:total-nodes-visited 0,      :depth 0,      :result false,      :smallest [0]}}</pre>    <p>这个测试尝试对100组生成的自然数（nat-int?）进行测试，但首次运行就发现代码发生过变动。失败的数据是0，而且还给出了最小失败集[0]。拿着这个最小失败集，我们就可以快速地重现失败用例，从而修正。</p>    <p>当然也存在这样的可能：在一次运行中，我们的测试无法发现失败的用例。但是，如果100个测试用例都通过了，至少表明我们程序对于100个随机的自然数都是正确的，和基于用例的测试相比，这就如同编织出一道更加紧密的安全网——网孔越小，漏掉的情况也越少。</p>    <p>Clojure语言之父Rich Hickey推崇Simple Made Easy哲学，受其影响生成式测试在Clojure.spec中有更为简约的表达。以上述为例：</p>    <pre>  (s/fdef identity-nat     :args (s/cat :a nat-int?) ; 输入参数的规格     :ret nat-int?             ; 返回结果的规格     :fn #(= (:ret %) (-> % :args :a))) ; 入参和出参之间的约束      (stest/check `identity-nat)</pre>    <p>fdef宏定义了方法identity-nat的规格，默认情况下会基于参数的规格生成1000组数据进行生成式测试。除了这一好处，它还提供部分类型检查的功能。</p>    <h2>再谈TDD</h2>    <p>TDD（测试驱动开发）是一种驱动代码实现和设计的过程。我们说要先有测试，再去实现；保证实现功能的前提下，重构代码以达到较好的设计。整个过程就好比演绎推理，测试就是其中的证明步骤，而最终实现的功能则是证明的结果。</p>    <p>对于开发人员而言，基于用例的测试方式是友好的，因为它能简单直接地表达实现的功能并保证其正确性。一旦进入红、绿、重构的节（guai）奏（quan），开发人员根本停不下来，仿佛遁入一种心流状态。只不过问题是，基于用例驱动出来的实现可能并不是恰好通过的。我们常常会发现，在写完上组测试用例的实现之后，无需任何改动，下组测试照常能运行通过。换句话说，实现代码可能做了多余的事情而我们却浑然不知。在这种情况下，我们可以利用生成式测试准备大量符合规格的数据探测程序，以此检查程序的健壮性，让缺陷无处遁形。</p>    <p>凡是想到的情况都能测试，但是想不到情况也需要测试，这才是生成式测试的价值所在。有人把TDD概念化为“展示你的功能”（Show your work），而把生成式测试归纳为“检查你的功能“（Check your work），我深以为然。</p>    <h2>小结</h2>    <p>回到我们写单元测试的动机上：</p>    <p>1、驱动和验证功能实现；</p>    <p>2、保护已有的功能不被破坏。</p>    <p>基于用例的单元测试和生成式测试在这两点上是相辅相成的。我们可以借助它们尽可能早地发现更多的缺陷，避免它们逃逸到生产环境。 ThoughtWorks 2016年11月份的技术雷达把Clojure.spec移到了工具象限的评估环中，这表明值得我们对它作一番探究。另外，除了Clojure，其它语言也有相应的生成式测试的框架，你不妨在自己的项目中试一试。</p>    <p> </p>    <p>来自：http://insights.thoughtworkers.org/improve-the-effectiveness-of-unit-testing/</p>    <p> </p>